Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Encoding function for 3GPP RLC/PDCP PDUs
Encoding function for 3GPP RLC/PDCP PDUs [message #1783390] Mon, 12 March 2018 14:52 Go to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey,

I am trying to build the 3GPP RLC AM testcases and created a minimal set of ttcn and ASN1 files for RLC_AM_Testcases.ttcn.

I've added manual encoding and decoding function for all ASN1 messages that require PER encoding and decoding but seem to be unable to tell Titan the correct type for all PDU types, like PDCP_PDU_Type and RLC_PDU_Type. I wanted to use the internal RAW coder and added something like this:
external function enc_PDCP_PDU(in PDCP_PDU_Type pdu) return octetstring
    with { extension "prototype(convert) encode(RAW)" };


But Titan doesn't pick it up.

/usr/bin/ttcn3_compiler -L  \
CommonDefs.ttcn CommonIP.ttcn CommonIratDefs.ttcn EPS_NAS_Constants.ttcn EPS_NAS_MsgContainers.ttcn EPS_NAS_Templates.ttcn EPS_NAS_TypeDefs.ttcn EUTRA_AspCommon_Templates.ttcn EUTRA_ASP_DrbDefs.ttcn EUTRA_ASP_NasCtrl.ttcn EUTRA_ASP_SrbDefs.ttcn EUTRA_ASP_TypeDefs.ttcn EUTRA_AuxiliaryFunctions.ttcn EUTRA_CapabilityFunctions.ttcn EUTRA_CellCfg_Templates.ttcn EUTRA_CellInfoFrequency.ttcn EUTRA_CellInfo.ttcn EUTRA_CommonDefs.ttcn EUTRA_CommonProcedures.ttcn EUTRA_Component.ttcn EUTRA_ConfigurationSteps.ttcn EUTRA_DRB_Templates.ttcn EUTRA_ExternalSecurityFunctions.ttcn EUTRA_LoopBack.ttcn EUTRA_LoopBack_TypeDefs.ttcn EUTRA_NASCommonTemplates.ttcn EUTRA_NASSteps.ttcn EUTRA_Paging.ttcn EUTRA_Parameters.ttcn EUTRA_PdcchConfig.ttcn EUTRA_RRCSteps.ttcn EUTRA_RRC_Templates.ttcn EUTRA_SecurityFunctions.ttcn EUTRA_SecuritySteps.ttcn EUTRA_Security_Templates.ttcn EUTRA_SRB_Templates.ttcn EUTRA_SysInfo_Templates.ttcn EUTRA_Timing.ttcn EUTRA_Types_Test.ttcn EUTRA_Types.ttcn IP_ASP_TypeDefs.ttcn IP_PTC_CtrlMsgs.ttcn L2_CommonFunctions.ttcn L2_CommonTemplates.ttcn NAS_AuxiliaryDefsAndFunctions.ttcn NAS_CommonTemplates.ttcn NAS_CommonTypeDefs.ttcn Parameters.ttcn PDCP_Testcases.ttcn RLC_AM_Templates.ttcn RLC_AM_Testcases.ttcn RLC_Common.ttcn TestcaseProperties.ttcn UpperTesterDefs.ttcn UpperTesterFunctions.ttcn UTRAN_CommonDefs.ttcn  EUTRA_RRC_ASN1_Definitions.asn - CommonDefs.ttcn CommonIP.ttcn CommonIratDefs.ttcn EPS_NAS_Constants.ttcn EPS_NAS_MsgContainers.ttcn EPS_NAS_Templates.ttcn EPS_NAS_TypeDefs.ttcn EUTRA_AspCommon_Templates.ttcn EUTRA_ASP_DrbDefs.ttcn EUTRA_ASP_NasCtrl.ttcn EUTRA_ASP_SrbDefs.ttcn EUTRA_ASP_TypeDefs.ttcn EUTRA_AuxiliaryFunctions.ttcn EUTRA_CapabilityFunctions.ttcn EUTRA_CellCfg_Templates.ttcn EUTRA_CellInfoFrequency.ttcn EUTRA_CellInfo.ttcn EUTRA_CommonDefs.ttcn EUTRA_CommonProcedures.ttcn EUTRA_Component.ttcn EUTRA_ConfigurationSteps.ttcn EUTRA_DRB_Templates.ttcn EUTRA_ExternalSecurityFunctions.ttcn EUTRA_LoopBack.ttcn EUTRA_LoopBack_TypeDefs.ttcn EUTRA_NASCommonTemplates.ttcn EUTRA_NASSteps.ttcn EUTRA_Paging.ttcn EUTRA_Parameters.ttcn EUTRA_PdcchConfig.ttcn EUTRA_RRCSteps.ttcn EUTRA_RRC_Templates.ttcn EUTRA_SecurityFunctions.ttcn EUTRA_SecuritySteps.ttcn EUTRA_Security_Templates.ttcn EUTRA_SRB_Templates.ttcn EUTRA_SysInfo_Templates.ttcn EUTRA_Timing.ttcn EUTRA_Types_Test.ttcn EUTRA_Types.ttcn IP_ASP_TypeDefs.ttcn IP_PTC_CtrlMsgs.ttcn L2_CommonFunctions.ttcn L2_CommonTemplates.ttcn NAS_AuxiliaryDefsAndFunctions.ttcn NAS_CommonTemplates.ttcn NAS_CommonTypeDefs.ttcn Parameters.ttcn PDCP_Testcases.ttcn RLC_AM_Templates.ttcn RLC_AM_Testcases.ttcn RLC_Common.ttcn TestcaseProperties.ttcn UpperTesterDefs.ttcn UpperTesterFunctions.ttcn UTRAN_CommonDefs.ttcn EUTRA_RRC_ASN1_Definitions.asn
warning: Charstring pattern: Environment variable TTCN3_DIR not present. Case-insensitive universal charstring patterns are disabled.

Notify: Parsing TTCN-3 module `CommonDefs.ttcn'...
Notify: Parsing TTCN-3 module `CommonIP.ttcn'...
Notify: Parsing TTCN-3 module `CommonIratDefs.ttcn'...
Notify: Parsing TTCN-3 module `EPS_NAS_Constants.ttcn'...
Notify: Parsing TTCN-3 module `EPS_NAS_MsgContainers.ttcn'...
Notify: Parsing TTCN-3 module `EPS_NAS_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EPS_NAS_TypeDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_AspCommon_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ASP_DrbDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ASP_NasCtrl.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ASP_SrbDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ASP_TypeDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_AuxiliaryFunctions.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CapabilityFunctions.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CellCfg_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CellInfoFrequency.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CellInfo.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CommonDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_CommonProcedures.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Component.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ConfigurationSteps.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_DRB_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_ExternalSecurityFunctions.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_LoopBack.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_LoopBack_TypeDefs.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_NASCommonTemplates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_NASSteps.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Paging.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Parameters.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_PdcchConfig.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_RRCSteps.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_RRC_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_SecurityFunctions.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_SecuritySteps.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Security_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_SRB_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_SysInfo_Templates.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Timing.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Types_Test.ttcn'...
Notify: Parsing TTCN-3 module `EUTRA_Types.ttcn'...
Notify: Parsing TTCN-3 module `IP_ASP_TypeDefs.ttcn'...
Notify: Parsing TTCN-3 module `IP_PTC_CtrlMsgs.ttcn'...
Notify: Parsing TTCN-3 module `L2_CommonFunctions.ttcn'...
Notify: Parsing TTCN-3 module `L2_CommonTemplates.ttcn'...
Notify: Parsing TTCN-3 module `NAS_AuxiliaryDefsAndFunctions.ttcn'...
Notify: Parsing TTCN-3 module `NAS_CommonTemplates.ttcn'...
Notify: Parsing TTCN-3 module `NAS_CommonTypeDefs.ttcn'...
Notify: Parsing TTCN-3 module `Parameters.ttcn'...
Notify: Parsing TTCN-3 module `PDCP_Testcases.ttcn'...
Notify: Parsing TTCN-3 module `RLC_AM_Templates.ttcn'...
Notify: Parsing TTCN-3 module `RLC_AM_Testcases.ttcn'...
Notify: Parsing TTCN-3 module `RLC_Common.ttcn'...
Notify: Parsing TTCN-3 module `TestcaseProperties.ttcn'...
Notify: Parsing TTCN-3 module `UpperTesterDefs.ttcn'...
Notify: Parsing TTCN-3 module `UpperTesterFunctions.ttcn'...
Notify: Parsing TTCN-3 module `UTRAN_CommonDefs.ttcn'...
Notify: Parsing ASN.1 module `EUTRA_RRC_ASN1_Definitions.asn'...
EUTRA_RRC_ASN1_Definitions.asn:7: warning: Missing IMPORTS clause is interpreted as `IMPORTS ;' (import nothing) instead of importing all symbols from all modules.
Notify: Checking modules...
EUTRA_Component.ttcn: In TTCN-3 module `EUTRA_Component':
 EUTRA_Component.ttcn:183.3-195.3: In function definition `f_EUTRA_ActivateDefault':
  EUTRA_Component.ttcn:185.5-44: In deactivate statement:
   EUTRA_Component.ttcn:185.5-44: warning: Calling `deactivate()' in a function or altstep. This might delete the `in' parameters of a currently running altstep.
 EUTRA_Component.ttcn:634.3-671.3: In function definition `f_EUTRA_ChangeSIB5_Combination3':
  EUTRA_Component.ttcn:644.43-84: In template variable definition `v_MIB':
   EUTRA_Component.ttcn:644.52-84: warning: Inadequate restriction on the referenced template variable `v_EUTRA_CellSysInfo.BCCH_Info.MIB', this may cause a dynamic test case error at runtime
   EUTRA_Component.ttcn:643.49-111: note: Referenced template variable is here
  EUTRA_Component.ttcn:646.46-94: In template variable definition `v_SI_SIB2':
   EUTRA_Component.ttcn:646.59-94: warning: Inadequate restriction on the referenced template variable `v_EUTRA_CellSysInfo.BCCH_Info.SIs[0]', this may cause a dynamic test case error at runtime
   EUTRA_Component.ttcn:643.49-111: note: Referenced template variable is here
  EUTRA_Component.ttcn:647.46-94: In template variable definition `v_SI_SIB3':
   EUTRA_Component.ttcn:647.59-94: warning: Inadequate restriction on the referenced template variable `v_EUTRA_CellSysInfo.BCCH_Info.SIs[1]', this may cause a dynamic test case error at runtime
   EUTRA_Component.ttcn:643.49-111: note: Referenced template variable is here
EUTRA_RRCSteps.ttcn: In TTCN-3 module `EUTRA_RRCSteps':
 EUTRA_RRCSteps.ttcn:815.3-822.3: In function definition `f_EUTRA_ModifySysinfo':
  EUTRA_RRCSteps.ttcn:821.5-71: In function instance:
   EUTRA_RRCSteps.ttcn:821.5-71: warning: The value returned by function `@EUTRA_RRCSteps.f_EUTRA_ModifySysinfo_ValueTag' is not used
 EUTRA_RRCSteps.ttcn:900.3-904.3: In function definition `f_EUTRA_ModifySysinfo_ValueTag_NoPaging':
  EUTRA_RRCSteps.ttcn:903.5-61: In function instance:
   EUTRA_RRCSteps.ttcn:903.5-61: warning: The value returned by function `@EUTRA_RRCSteps.f_EUTRA_ModifySysinfo_ValueTag' is not used
 EUTRA_RRCSteps.ttcn:906.3-915.3: In function definition `f_EUTRA_ModifySysinfoUE_Off':
  EUTRA_RRCSteps.ttcn:911.5-61: In function instance:
   EUTRA_RRCSteps.ttcn:911.5-61: warning: The value returned by function `@EUTRA_RRCSteps.f_EUTRA_ModifySysinfo_ValueTag' is not used
EUTRA_NASSteps.ttcn: In TTCN-3 module `EUTRA_NASSteps':
 EUTRA_NASSteps.ttcn:369.3-421.3: In function definition `f_EUTRA_UE_Detach_SwitchOffUe':
  EUTRA_NASSteps.ttcn:391.7-415.9: In if statement:
   EUTRA_NASSteps.ttcn:394.11-412.11: In select case statement:
    EUTRA_NASSteps.ttcn:396.13-404.15: In select case statement:
     EUTRA_NASSteps.ttcn:398.17-403.109: In function instance:
      EUTRA_NASSteps.ttcn:398.17-403.109: warning: The value returned by function `@EUTRA_NASSteps.f_EUTRA_RRC_ConnEst_DefWithNas' is not used
 EUTRA_NASSteps.ttcn:627.3-673.3: In function definition `f_EUTRA_ServiceRequestAndActivate_SRB2_DRB':
  EUTRA_NASSteps.ttcn:656.5-666.71: In function instance:
   EUTRA_NASSteps.ttcn:675.3-708.3: In function definition `f_EUTRA_Activate_SRB2_DRB_SendRrcMsg':
    EUTRA_NASSteps.ttcn:698.5-707.75: In function instance:
     EUTRA_NASSteps.ttcn:710.3-834.3: In function definition `f_EUTRA_Activate_SRB2_DRB_SendRrcMsg_Step8':
      EUTRA_NASSteps.ttcn:806.7-814.5: In else statement:
       EUTRA_NASSteps.ttcn:807.7-813.7: In for statement:
        EUTRA_NASSteps.ttcn:811.9-812.107: In variable assignment:
         EUTRA_NASSteps.ttcn:811.43-812.107: In actual parameter list of template `@EPS_NAS_Templates.cs_NAS_Request':
          EUTRA_NASSteps.ttcn:812.44-106: In parameter #2 for `p_Msg':
           EUTRA_NASSteps.ttcn:812.72-106: In actual parameter list of template `@EPS_NAS_Templates.cs_ActDedEPSBearerCxtReq_QoS':
            EUTRA_NASSteps.ttcn:812.88-95: In parameter #2 for `p_QoS':
             EUTRA_NASSteps.ttcn:812.88-95: warning: Inadequate restriction on the referenced template parameter `p_QoS[i]', this may cause a dynamic test case error at runtime
             EUTRA_NASSteps.ttcn:717.55-100: note: Referenced template parameter is here
            EUTRA_NASSteps.ttcn:812.98-105: In parameter #3 for `p_Tft':
             EUTRA_NASSteps.ttcn:812.98-105: warning: Inadequate restriction on the referenced template parameter `p_Tft[i]', this may cause a dynamic test case error at runtime
             EUTRA_NASSteps.ttcn:718.55-97: note: Referenced template parameter is here
EUTRA_Types_Test.ttcn: In TTCN-3 module `EUTRA_Types_Test':
 EUTRA_Types_Test.ttcn:42.3-52.3: In testcase definition `tc_encdec':
  EUTRA_Types_Test.ttcn:44.5-20: In function instance:
   EUTRA_Types_Test.ttcn:44.5-20: warning: The value returned by external function `@EUTRA_Types.enc_DCC_PDU' is not used
EUTRA_ASP_DrbDefs.ttcn:397.8-402.3: error: Cannot determine the encoding rules for type `@EUTRA_ASP_DrbDefs.PDCP_PDU_Type'. No encoding external functions found
EUTRA_ASP_DrbDefs.ttcn:329.8-334.3: error: Cannot determine the encoding rules for type `@EUTRA_ASP_DrbDefs.RLC_PDU_Type'. No encoding external functions found
EUTRA_ASP_DrbDefs.ttcn:309.8-317.3: error: Cannot determine the decoding rules for type `@EUTRA_ASP_DrbDefs.RLC_AM_StatusPDU_Type'. No decoding external functions found
Notify: Errors found in the input modules. Code will not be generated.
Makefile:173: recipe for target 'compile' failed
make: *** [compile] Error 1


Any pointers or other example that use those 3GPP testcases are highly appreciated. I am also not entirely sure if I am supposed to use the RAW encoder in this situation at all.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783412 is a reply to message #1783390] Mon, 12 March 2018 18:28 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

unfortunately the RAW codec cannot be applied here.
Of the ASN.1 codecs Titan supports only BER and (partly) OER.

please read the below entry:
Eclipse Titan and the dilemma of PER-encoding
https://www.eclipse.org/forums/index.php/t/1070344/

where it is explained in detail how an external PER-codec can be used in Titan.

You probably have two options: use a commercial codec or the open source asn1c , if it supports your ASN.1.

Best regards
Elemer

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783510 is a reply to message #1783412] Tue, 13 March 2018 17:35 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

thanks for your prompt reply. I am aware of the ASN1 PER problematic in Titan and have already started to write the encoders and decoders using asn1c (open source with PER support) for those types that are actually ASN1 encoded.

However, the problem I was seeing was with RLC and PDCP PDU types which are not ASN1 encoded, and hence my question. Meanwhile I have circumvented the error by defining the codec to be XML. I also tried RAW but that didn't work either, but it should, right?

module EUTRA_ASP_DrbDefs {
  ..
  ..
  type record of PDCP_PDU_Type PDCP_PDUList_Type;

  } // End sub-group PDCP

  //} with { encode "DRB Types"} // End group PDU_TypeDefs
  } with { encode "XML"}


After fixing a number of errors relating to external functions and ports by defining them "internal" as has been done in your (excellent) porting guides I was able to compile the suite.

It still doesn't link because I haven't implemented those function I marked internal yet (mainly security function for key derivation etc). However, I am actually more concerned about the ports I marked internal. What's the most appropriate way to actually implement those? I am planning to connect those ports via a socket to my IUT. Are translation ports the right way to go here, like you did in the SNMP example?

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783564 is a reply to message #1783510] Wed, 14 March 2018 07:54 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre.

sorry, my bad, I should have looked into it in more detail.


In order for Titan to generate the appropriate RAW codecs , you need
1) a final with { encode "RAW"}
2) at least an empty with { variant "" } decorating the types you intend to encode/decode - I'm guessing this is what is missing in your case
(if an empty variant is attached, Titan will generate default encodings, which may not be what you are after)
3) either a purposefully declared external function , or usage of encvalue/decvalue

to refer to your example:
module EUTRA_ASP_DrbDefs {

external function enc_PDCP_PDU(in PDCP_PDU_Type pdu) return octetstring     
with { extension "prototype(convert) encode(RAW)" };
external function dec_PDCP_PDU(in octetstring stream) return PDCP_PDU
 with { extension "prototype(convert) decode(RAW)" };
  ..
  ..
  type record of PDCP_PDU_Type PDCP_PDUList_Type with { variant "" };

  } // End sub-group PDCP


  } with { encode "RAW"}





Translation ports are just a clever way to reuse ports for lower layers (like TCP, UDP ) for a higher level transport (e.g. HTTP, SNMP).

I guess you should look into IPL4 which can be used in UDP/TCP/SCTP mode and build a translation from that to your higher level protocol.
Alternatively you can write your own port , which usually start with generating a skeleton (see apiguide) and then adding your specific code.



I hope this helps somewhat

BR ELemer



Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783612 is a reply to message #1783564] Wed, 14 March 2018 15:06 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemar,

no worries at all. After applying your suggestion with "with {variant ""}" on all types and subtypes it generated the code without issues. I've now also added dummy functions for all those functions I declared external and the project compiles and links now.

I am now trying to execute a simple dummy test case that actually just encodes a type into a ASN1 and succeeds then. The entire project, however, contains many more modules that are all loaded and initialized on startup but seem to fail.

$ ttcn3_start ./rlctester ../RLC_Test.cfg
ttcn3_start: Starting the test suite
ttcn3_start: warning: TTCN3_DIR environment variable is not set
spawn mctr_cli ../RLC_Test.cfg

*************************************************************************
* TTCN-3 Test Executor - Main Controller 2                              *
* Version: CRL 113 200/6 R2A                                            *
* Copyright (c) 2000-2017 Ericsson Telecom AB                           *
* All rights reserved. This program and the accompanying materials      *
* are made available under the terms of the Eclipse Public License v1.0 *
* which accompanies this distribution, and is available at              *
* http://www.eclipse.org/legal/epl-v10.html                             *
*************************************************************************

Using configuration file: ../RLC_Test.cfg
MC@andre-xps13: Unix server socket created successfully.
MC@andre-xps13: Listening on TCP port 40777.
MC2> andre-xps13 is the default
spawn ././rlctester andre-xps13 40777
TTCN-3 Host Controller (parallel mode), version CRL 113 200/6 R2A
MC@andre-xps13: New HC connected from localhost [127.0.0.1]. andre-xps13: Linux 4.13.0-36-generic on x86_64.
cmtc
MC@andre-xps13: Downloading configuration file to all HCs.
HC@andre-xps13: CommonDefs.ttcn:227: Dynamic test case error: Accessing an element of an unbound charstring value.
Error: There were errors during configuring HCs.
Error during initialization. Cannot create MTC.
MC2> ttcn3_start: error: the MTC cannot be created. 
exit
MC@andre-xps13: Shutting down session.
MC@andre-xps13: Shutdown complete.


The actual code in that file (which comes from the 3gpp test suite) is like follow:
var integer v_StrLen := lengthof(p_String);


It's actually only used in a number of templates that are, however, not used themselves in any test case. Any idea how to get rid of this? Or is exactly this, i.e. the fact that it is not really used, the issue? The problem is that the 3gpp testsuite does use it in some other testcases but I thought it would be easier to start with a project that only includes a few testcases rather than the whole beast.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783620 is a reply to message #1783612] Wed, 14 March 2018 16:23 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

without the the code and the complete log all I can tell you is that you should trace back the p_String and find out where it should originate its value from.
This early in the initialization phase should not be too complicated.
If you are lucky it originates in an uninitialized module parameter which you can then simply initialize from the configuration file.

If you are not restricted by copyright, confidentiality etc. and can upload your example , I can take a look.

Best regards
Elemer



Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783695 is a reply to message #1783620] Thu, 15 March 2018 16:04 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

thanks. I tried to trace the issue back but as I said, the module that eventually uses the template is not even included in the project. But maybe I am overseeing something here. Anyway, I uploaded the example to https://github.com/andrepuschmann/ttcn3_rlc. The project require the 3GPP UE testcases that need to be placed in the ue_testcases folder. There is also a diff that needs to be applied to the ttcn files once they are unpacked. I didn't put them into the repo because I wasn't sure about the license, but I don't think I am supposed to do that without permission. The repo also contains a build folder with an example Makefile that includes the modifications for finding the includes and libs for ASN1 decoding. But you can regenerate those by calling ../install.sh from the build folder.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783709 is a reply to message #1783695] Fri, 16 March 2018 07:14 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

here's what happens: Titan is trying to initialize whatever could not be initialized during compilation; this practically means everything that depends on
module parameters that are initialized during runtime, from values set in the configuration file.

For instance it will try to initialize
 template (value) PacketFilterComponent cs_PktFilterCompIPv4RemoteAddress :=
  { // 9 octets
    /* @status    APPROVED */
    id := '10'O, // IPv4 remote address
    packetFilterComponentValue := {
      ipv4RemoteAddress := f_Convert_IPv4Addr2OctString(px_IPv4_RemoteAddress) & tsc_IPv4Mask // R5s100189
    }
  };
 

whose value depends from px_IPv4_RemoteAddress;

so it will call
  function f_Convert_IPv4Addr2OctString(charstring p_IPv4AddrChar) return O4_Type
  {
    var Char1List_Type v_SplitCharList := {"."};
    var CharStringList_Type v_FieldList := f_StringSplit(p_IPv4AddrChar, v_SplitCharList);
    var octetstring v_IPv4AddrOct := ''O;
    var integer v_FieldCnt := lengthof(v_FieldList);
    var integer v_IntVal;
    var integer i;

    if (v_FieldCnt != 4) {
      FatalError(__FILE__, __LINE__, "invalid IP Address");
    }
    for (i:=0; i<v_FieldCnt; i:=i+1) {
      v_IntVal := str2int(v_FieldList[i]);
      v_IPv4AddrOct := v_IPv4AddrOct & int2oct(v_IntVal, 1);
    }
    return v_IPv4AddrOct;
  }

with px_IPv4_RemoteAddress

which will invoke f_StringSplit with px_IPv4_RemoteAddress as input,
which finally calls lengthof( px_IPv4_RemoteAddress)
but problem is that px_IPv4_RemoteAddress is not initialized as it can be seen from the log:

07:42:25.178406 - TTCN-3 Host Controller started on GlobalWarning1. Version: CRL 113 200/6 R3A.
07:42:25.178473 - TTCN Logger v2.2 options: TimeStampFormat:=Time; LogEntityName:=No; LogEventTypes:=No; SourceInfoFormat:=Single; *.FileMask:=LOG_ALL | DEBUG; *.ConsoleMask:=ERROR | USER; LogFileSize:=0; LogFileNumber:=1; DiskFullAction:=Error
07:42:25.178974 - The address of MC was set to GlobalWarning1[127.0.1.1]:0.
07:42:25.179281 - The local IP address of the control connection to MC is 127.0.0.1.
07:42:25.179316 - Connected to MC.
07:42:25.179397 - This host supports UNIX domain sockets for local communication.
07:42:25.180083 - Processing configuration data received from MC.
07:42:25.180809 - Module EUTRA_Parameters has the following parameters: { px_MaxNumberROHC_ContextSessions := cs16 (4), px_NAS_CipheringAlgorithm := '000'B, px_NAS_IntegrityProtAlgorithm := '001'B, px_RRC_CipheringAlgorithm := eea0 (0), px_RRC_IntegrityProtAlgorithm := eia1 (1), px_eSecondaryBandChannelBandwidth := n25 (2), px_eTDDsubframeConfig := sa1 (1), px_eUE_Category_Type := 1, pc_eBand10_Supp := false, pc_eBand11_Supp := false, pc_eBand12_Supp := false, pc_eBand13_Supp := false, pc_eBand14_Supp := false, pc_eBand17_Supp := false, pc_eBand18_Supp := false, pc_eBand19_Supp := false, pc_eBand1_Supp := false, pc_eBand20_Supp := false, pc_eBand21_Supp := false, pc_eBand2_Supp := false, pc_eBand33_Supp := false, pc_eBand34_Supp := false, pc_eBand35_Supp := false, pc_eBand36_Supp := false, pc_eBand37_Supp := false, pc_eBand38_Supp := false, pc_eBand39_Supp := false, pc_eBand3_Supp := false, pc_eBand40_Supp := false, pc_eBand41_Supp := false, pc_eBand42_Supp := false, pc_eBand43_Supp := false, pc_eBand4_Supp := false, pc_eBand5_Supp := false, pc_eBand6_Supp := false, pc_eBand7_Supp := false, pc_eBand8_Supp := false, pc_eBand9_Supp := false }
07:42:25.180924 - Module Parameters has the following parameters: { px_AccessPointName := <unbound>, px_AttachTypeTested := EPS_ATTACH_ONLY (0), px_AuthAMF := <unbound>, px_AuthK := '00000000000000010000001000000011000001000000010100000110000001110000100000001001000010100000101100001100000011010000111000001111'B, px_DelayBeforeIntraCellHO := 300, px_IMEI_Def := <unbound>, px_IMSI_Def := '001010123456063'H, px_IPv4_Address := <unbound>, px_IPv4_Address2 := <unbound>, px_IPv4_RemoteAddress := <unbound>, px_IPv4viaNAS_TestMode := false, px_IPv6_Address := <unbound>, px_IPv6_Address2 := <unbound>, px_IPv6_RemoteAddress := <unbound>, px_PTMSI_Def := 'C2345678'O, px_PTMSI_SigDef := 'AB1234'O, px_SMS_ChkMsgReceived := true, px_SMS_IndexOffset := 0, px_SMS_PrefMem1 := "SM", px_SMS_PrefMem2 := "SM", px_SMS_PrefMem3 := "MT", px_SMS_Service := "0", px_TMSI_Def := '12345678'O, px_eAuthRAND := '10100011110111100000110001101101001101100011111000110000110000110110010010100100000001111000111100011011111110001101010101110111'B, px_eJapanMCC_Band6 := '442'H, px_ePrimaryBandChannelBandwidth := n25 (2), px_ePrimaryFrequencyBand := 1, px_eSecondaryFrequencyBand := 2, pc_1xCSfallback := false, pc_1xRTT := false, pc_Allowed_CSG_list := false, pc_Attach := false, pc_Automatic_Re_Attach := false, pc_CS := false, pc_CS_Fallback := false, pc_CS_SMS_only := false, pc_Combined_Attach := false, pc_DSMIPv6 := false, pc_EMM_Information := false, pc_EPS_Disable := false, pc_ESM_MO_Bearer_Allocation := false, pc_ESM_MO_Bearer_Modification := false, pc_ETWS_message := false, pc_ETWS_message_security := false, pc_FDD := true, pc_FeatrGrp_1 := false, pc_FeatrGrp_10 := false, pc_FeatrGrp_11 := false, pc_FeatrGrp_12 := false, pc_FeatrGrp_13 := false, pc_FeatrGrp_14 := false, pc_FeatrGrp_15 := false, pc_FeatrGrp_16 := false, pc_FeatrGrp_17 := false, pc_FeatrGrp_18 := false, pc_FeatrGrp_19 := false, pc_FeatrGrp_2 := false, pc_FeatrGrp_20 := false, pc_FeatrGrp_21 := false, pc_FeatrGrp_22 := false, pc_FeatrGrp_23 := false, pc_FeatrGrp_24 := false, pc_FeatrGrp_25 := false, pc_FeatrGrp_26 := false, pc_FeatrGrp_27 := false, pc_FeatrGrp_3 := false, pc_FeatrGrp_4 := false, pc_FeatrGrp_5 := false, pc_FeatrGrp_6 := false, pc_FeatrGrp_7 := false, pc_FeatrGrp_8 := false, pc_FeatrGrp_9 := false, pc_FullNameNetwork := false, pc_GERAN := false, pc_GERAN_2_E_UTRAN_meas := false, pc_HO_from_UTRA := false, pc_HRPD := false, pc_IMS := false, pc_IMS_emergency_call := false, pc_IPv4 := true, pc_IPv6 := false, pc_ISR := false, pc_ImmConnect := false, pc_LocalTimeZone := false, pc_Multiple_PDN := false, pc_PS := true, pc_RequestIPv4HAAddress_DuringAttach := false, pc_RequestIPv6HAAddress_DuringAttach := false, pc_SMS_SGs_MO := false, pc_SMS_SGs_MT := false, pc_ShortNameNetwork := false, pc_Speech := false, pc_SupportOpModeA := false, pc_SwitchOnOff := true, pc_TDD_HCR := false, pc_TDD_LCR := false, pc_TDD_VHCR := false, pc_USIM_Rmv := false, pc_UTRA := false, pc_UTRA_CompressedModeRequired := false, pc_UTRA_FeatrGrp_1 := false, pc_UTRA_FeatrGrp_2 := false, pc_UniversalAndLocalTimeZone := false, pc_data_centric := false, pc_eFDD := false, pc_eTDD := false, pc_not_SMS_only := false, pc_ue_Category_1 := false, pc_ue_Category_2 := false, pc_ue_Category_3 := false, pc_ue_Category_4 := false, pc_ue_Category_5 := false, pc_voice_centric := false }
07:42:25.181117 - Module SRSLTE_RLC_Test has the following parameters: { mp_ue_ip := "127.0.0.1", mp_ue_ctrl_port := 4255 }
07:42:25.181170 - Initializing module CommonDefs.
07:42:25.181215 - Initialization of module CommonDefs finished.
07:42:25.181257 - Initializing module CommonIP.
07:42:25.181299 - Initialization of module CommonIP finished.
07:42:25.181341 - Initializing module CommonIratDefs.
07:42:25.181382 CommonIratDefs.ttcn:0 Initializing module NAS_AuxiliaryDefsAndFunctions.
07:42:25.181438 NAS_AuxiliaryDefsAndFunctions.ttcn:0 Initializing module NAS_CommonTemplates.
07:42:25.181485 NAS_CommonTemplates.ttcn:0 Initializing module NAS_CommonTypeDefs.
07:42:25.181532 NAS_CommonTemplates.ttcn:0 Initialization of module NAS_CommonTypeDefs finished.
07:42:25.181700 NAS_AuxiliaryDefsAndFunctions.ttcn:0 Initialization of module NAS_CommonTemplates finished.
07:42:25.181762 NAS_AuxiliaryDefsAndFunctions.ttcn:0 Initializing module Parameters.
07:42:25.181809 Parameters.ttcn:0 Initializing module EUTRA_CommonDefs.
07:42:25.181855 Parameters.ttcn:0 Initialization of module EUTRA_CommonDefs finished.
07:42:25.181900 NAS_AuxiliaryDefsAndFunctions.ttcn:0 Initialization of module Parameters finished.
07:42:25.181959 CommonDefs.ttcn:226 Dynamic test case error: Performing lengthof operation on an unbound charstring value.
07:42:25.182069 CommonDefs.ttcn:226 Performing error recovery.
07:42:25.182423 - Initialization of modules failed.
07:42:25.183197 - Exit was requested from MC. Terminating HC.
07:42:25.183478 - Disconnected from MC.
07:42:25.183542 - TTCN-3 Host Controller finished.


wherever you see <unbound>, there's an uninitialized module parameter, so first you have to give them some value in your configuration file ;
without that , the initialization will not be able to finish.


Two notes here:
-of course you know, but for completeness only:

your main module
module SRSLTE_RLC_Test
{
  type component Empty_CT {
  
  }

  modulepar {
    /* remote parameters of IUT */
    charstring mp_ue_ip := "127.0.0.1";
    integer mp_ue_ctrl_port := 4255;
  }
  
  // Dummy test case
  testcase tc_dummy() runs on Empty_CT {
    setverdict(pass);
  }
  
  control {
    execute( tc_dummy() );
  }
}



has no dependencies so it can be compiled and run on its' own

-the entire project is large-ish so it probably takes you (too ) a while to compile ;

to speed up compilation I recommend you regenerate your Makefile with the - U option, e.g.
makefilegen -U 8   ... 
.
and possibly use the gold linker,

see this post for details:

Compilation of big files
https://www.eclipse.org/forums/index.php/t/1085369/



Hope this will be of help

Best regards
Elemer

[Updated on: Fri, 16 March 2018 07:56]

Report message to a moderator

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783718 is a reply to message #1783709] Fri, 16 March 2018 09:28 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

a skeleton example for your config file could be:

[LOGGING]
#LogFile := "logs/%l/%e.%h-%t%r.%s"
FileMask := LOG_ALL | TTCN_ERROR | TTCN_USER | TTCN_PORTEVENT  |  TTCN_DEBUG 
#| TTCN_MATCHING | TTCN_WARNING | TTCN_TESTCASE | TTCN_STATISTICS 
ConsoleMask := TTCN_ERROR | TTCN_USER 
#| TTCN_PORTEVENT
LogSourceInfo := Yes

[MODULE_PARAMETERS]


Parameters.px_IPv4_Address := "127.0.0.1"
:
:
[TESTPORT_PARAMETERS]
 

[MAIN_CONTROLLER]
TCPPort := 8035
KillTimer := 1.0

[EXECUTE]
SRSLTE_RLC_Test.control




BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783733 is a reply to message #1783718] Fri, 16 March 2018 12:02 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey Elemer,

thanks for the example, I've set the module parameter directly in the Parameters.ttcn but that way it's of course much easier.

I've now extended the example to include the full RLC UM tests cases and it now complains about that messages cant be sent over the internal ports.

But I have investigate this further and may come back to you later on. Any comments on this are of course still welcome.

ttcn3_start ./rlctest ../RLC_Test.cfg
ttcn3_start: Starting the test suite
ttcn3_start: warning: TTCN3_DIR environment variable is not set
spawn mctr_cli ../RLC_Test.cfg

*************************************************************************
* TTCN-3 Test Executor - Main Controller 2                              *
* Version: CRL 113 200/6 R2A                                            *
* Copyright (c) 2000-2017 Ericsson Telecom AB                           *
* All rights reserved. This program and the accompanying materials      *
* are made available under the terms of the Eclipse Public License v1.0 *
* which accompanies this distribution, and is available at              *
* http://www.eclipse.org/legal/epl-v10.html                             *
*************************************************************************

Using configuration file: ../RLC_Test.cfg
MC@andre-xps13: Unix server socket created successfully.
MC@andre-xps13: Listening on TCP port 38959.
andre-xps13 is the default
MC2> spawn ././rlctest andre-xps13 38959
TTCN-3 Host Controller (parallel mode), version CRL 113 200/6 R2A
MC@andre-xps13: New HC connected from localhost [127.0.0.1]. andre-xps13: Linux 4.13.0-36-generic on x86_64.
cmtc
MC@andre-xps13: Downloading configuration file to all HCs.
MC@andre-xps13: Configuration file was processed on all HCs.
MC@andre-xps13: Creating MTC on host localhost.
MC@andre-xps13: MTC is created.
MC2> smtc
Executing all items of [EXECUTE] section.
MC2> MTC@andre-xps13: Execution of control part in module SRSLTE_RLC_Test started.
MTC@andre-xps13: Test case tc_dummy started.
MTC@andre-xps13: Test case tc_dummy finished. Verdict: pass
MTC@andre-xps13: Test case TC_7_2_2_1 started.
MTC@andre-xps13: MTC_UpperTester.ttcn:360: Dynamic test case error: Message cannot be sent to system on internal port Ut.
3@andre-xps13: EUTRA_ConfigurationSteps.ttcn:74: Dynamic test case error: Message cannot be sent to system on internal port SYS.
MTC@andre-xps13: Test case TC_7_2_2_1 finished. Verdict: error
MTC@andre-xps13: Execution of control part in module SRSLTE_RLC_Test finished.
MC@andre-xps13: Test execution finished.
Execution of [EXECUTE] section finished.
emtc
MC@andre-xps13: Terminating MTC.
MTC@andre-xps13: Verdict statistics: 0 none (0.00 %), 1 pass (50.00 %), 0 inconc (0.00 %), 0 fail (0.00 %), 1 error (50.00 %).
MTC@andre-xps13: Test execution summary: 2 test cases were executed. Overall verdict: error
MC@andre-xps13: MTC terminated.
MC2> exit
MC@andre-xps13: Shutting down session.
MC@andre-xps13: Shutdown complete.


Thanks again

Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783740 is a reply to message #1783733] Fri, 16 March 2018 13:06 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

this is the console log;

could you attache the logfiles that are generated?



BR
Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783766 is a reply to message #1783740] Fri, 16 March 2018 16:57 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey,

sure. Here you go.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783768 is a reply to message #1783766] Fri, 16 March 2018 17:10 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

what's most likely happening here is that you are trying to send a message on a port that, although it is marked internal ,
it is mapped to the system so it is supposed to have a communication stack connected.

You should add a test port here (this is the upper tester so it connects to the SUT and it is supposed to trigger some messages from it)
and remove the internal markings.

BTW, I don't see much point in running this code before the missing parts have been added.


BR

Elemer

[Updated on: Fri, 16 March 2018 17:11]

Report message to a moderator

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783769 is a reply to message #1783768] Fri, 16 March 2018 17:19 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
About what the upper tester does, see

https://www.eclipse.org/forums/index.php/t/1079814/

BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1783773 is a reply to message #1783769] Fri, 16 March 2018 18:36 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

thanks for the forum link. DIdn't find that before.

Quote:
BTW, I don't see much point in running this code before the missing parts have been added.

Yes, I totally agree. I'll work on the other parts of the system next week and may get back to you with more specific question further down the path.

Thanks again
Andre

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1784043 is a reply to message #1783773] Wed, 21 March 2018 21:34 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi all,

in order to interface the EUTRA_PTC with my DUT I've created a dual-faced port that converts, for example, the SYSTEM_CTRL_REQ and SYSTEM_CTRL_CNF messages, and transmits/receives them over UDP using the IPL4 port. Part of the (incomplete) port definition is below. I am now wondering about the best way to implement the connect call, or to be precise, the best place to put the connect function? Since the EUTRA_IPL4_PT port is part of the EUTRA_PTC component, it should be called in one of the init function of the component, right? However, In most of the examples I've studied so far, connecting the port is done in the testcase directly, which in my case usually "runs on MTC system SYSTEM" and hence I cannot call the init from there. I guess it's an easy one but I don't seem to find a good and portable way to achieve this.

Thanks
Andre

The UDP connect function that should be called on EUTRA_PTC.

function f_openConnection(in ConnectionParams pl_connectionParams, integer pl_connId)
  runs on EUTRA_PTC return integer
  {
     var Socket_API_Definitions.Result vl_result;
     vl_result := IPL4asp_User_CtrlFunct.f_IPL4_connect(SYS,
       pl_connectionParams.remHost,
       pl_connectionParams.remPort,
       pl_connectionParams.locHost,
       pl_connectionParams.locPort,
       pl_connId, //pl_connectionParams.connId,
       {udp := {}}    
    );
    log(vl_result)
    return(vl_result.connId)
  }


And here the definition of the dual-faced port.

type port EUTRA_IPL4_PT message
{
 out 
     SYSTEM_CTRL_REQ
 in      
     SYSTEM_CTRL_CNF,
     ASP_Event          
}with 
{ extension 
   "user IPL4asp_PT
      out(
        SYSTEM_CTRL_REQ -> ASP_Send: function(f_enc_SYSTEM_CTRL_REQ_DualFace)
    )    
      in(
        ASP_RecvFrom -> SYSTEM_CTRL_CNF : function(f_dec_SYSTEM_CTRL_CNF_DualFace);
        ASP_Event -> ASP_Event : simple
    )
   " 
   //extension "address" - not possible with current Titan
}

function f_enc_SYSTEM_CTRL_REQ_DualFace
( in SYSTEM_CTRL_REQ pl_in,
  out ASP_Send pl_out) return integer
{
  pl_out.connId := -1;
  pl_out.msg := 'AA'O;
  pl_out.proto := omit; 
  
  return 0;
}with {extension "prototype(backtrack)" }
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1784085 is a reply to message #1784043] Thu, 22 March 2018 10:47 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

yes, in case your test case involves parallel components, the sensible thing to do is to create and start them from the MTC , then at the beginning of the function started on the component call f_openConnection ;
for UDP, mind, it's not really a connection, maybe "association" is the right word?

f_openConnection will return a connection Id that has to be reused when referring to the communication channel

This means that using "-1" for connection id e.g. here


function f_enc_SYSTEM_CTRL_REQ_DualFace
( in SYSTEM_CTRL_REQ pl_in,
  out ASP_Send pl_out) return integer
{
  pl_out.connId := -1;
  pl_out.msg := 'AA'O;
  pl_out.proto := omit; 
  
  return 0;
}with {extension "prototype(backtrack)" }


will not work( as you should use here the value returned by f_openConnection) , with the following exception:


If you expect to have only one UDP ( or TCP) channel along the duration of your test case, you can use the following simplification:
the connection can be controlled not only from f_openConnection, but directly from the map operation , meaning that when mapped, the port will open automatically a connection with parameters taken from the config file;

if , on top of that , lazy_conn_id_handling is set to yes (and only one comms channel in the system, which can be unequivocally referred to) ,
then the user does not have to care about the real value of the connection id , the dummy value -1 can be used instead.

This means that you can skip the f_openConnectionFunction but have to use in the config file something like:


*.portName.defaultListeningPort				:= "0"  
*.portName.map_behavior					:= "connect"  
*.portName.RemotePort						:= "666"			 // SUT - Port
*.portName.RemoteHost						:= "127.0.0.1"   // SUT - IP    
*.portName.lazy_conn_id_handling			       := "yes"  
*.portName.debug                                                     := "yes" //or "no"
*.mccPort.map_protocol                                           := "udp"



For obvious reasons this setup can handle one connection only ; with f_connect() , f_close() etc. , any number of connections can be opened or closed flexibly at any moment.

So this is an early design decision one will have to take.

Besides , the reasoning is not valid for listening ports , when the other side will open the connection and set the connection Id.

One more thing: dual-faced-ports will work just as fine, but you might have more flexibiilty and features eventually with the standard-compliant translation ports.



Hope this helps

Elemer

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785533 is a reply to message #1784085] Mon, 16 April 2018 12:01 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey Elemer,

sorry for not getting back any earlier. The project is still alive but I needed to park it for a bit. I've made some progress with transfering the ports from dual-faced ports to translation ports and can also build the system ok. However, I am still facing some issue connecting the MTC and specfically its UpperTester interface to my DUT. I am specifically trying to get the MTC_System_Ut port (defined in MTC_Component.ttcn) which connects the nested SYSTEM componet with the MTC to work. I've updated the example code on github accordingly [1] but have a few question regarding it. First, is my understanding correct that SYSTEM is just nested in MTC, that I leave the port between SYSTEM and MTC a MTC_System_Ut and that I need to define another component that "maps" between MTC_System_Ut and my IPL4-version of it? The current code doesnt do that though.

The problem right now is that even if I am not doing the connection opening correctly, I should see the TTCN3 log when the Tx function of the translation port is called, which I am not.

I've updated the example on github accordingly if anyone whats to have a look but let me know if my problem needs more clarification.

Thanks
Andre

[1] https://github.com/andrepuschmann
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785587 is a reply to message #1785533] Tue, 17 April 2018 08:19 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

I ftp-d the test cases:
esekilxxen1841 [8:31] [Andre/ttcn3_rlc/ue_testcases] -> wget  ftp://ftp.3gpp.org/Specs/archive/36_series/36.523-3/36523-3-860.zip
--2018-04-17 08:32:06--  ftp://ftp.3gpp.org/Specs/archive/36_series/36.523-3/36523-3-860.zip                                     
           => `36523-3-860.zip'                                                                                                  
Resolving ftp.3gpp.org... 195.238.226.35                                                                                         
Connecting to ftp.3gpp.org|195.238.226.35|:21... connected.                                                                      
Logging in as anonymous ... Logged in!                                                                                           
==> SYST ... done.    ==> PWD ... done.                                                                                          
==> TYPE I ... done.  ==> CWD /Specs/archive/36_series/36.523-3 ... done.                                                        
==> SIZE 36523-3-860.zip ... 2753747                                                                                             
==> PASV ... done.    ==> RETR 36523-3-860.zip ... done.                                                                         
Length: 2753747 (2.6M)                                                                                                           

100%[==================================================================================================>] 2,753,747   1.60M/s   in 1.6s    

2018-04-17 08:32:08 (1.60 MB/s) - `36523-3-860.zip' saved [2753747]



applied the patch:

esekilxxen1841 [8:46] [Andre/ttcn3_rlc/ue_testcases] -> patch -p1 -i 3gpp_testcases.diff                             
patching file CommonEUTRA_Defs/EPS_NAS_MsgContainers.ttcn                                                            
patching file CommonEUTRA_Defs/EUTRA_ASP_DrbDefs.ttcn                                                                
patching file CommonEUTRA_Defs/EUTRA_ASP_NasCtrl.ttcn                                                                
patching file CommonEUTRA_Defs/EUTRA_ASP_SrbDefs.ttcn                                                                
patching file CommonEUTRA_Defs/EUTRA_ASP_TypeDefs.ttcn                                                               
patching file CommonUTRAN/UTRAN_CommonDefs.ttcn                                                                      
patching file IP_PTC/DHCPv4_TypeDefs.ttcn                                                                            
patching file IP_PTC/ICMPv6_TypeDefs.ttcn                                                                            
patching file IP_PTC/IP_ASP_TypeDefs.ttcn                                                                            
patching file IP_PTC/IP_PTC_CtrlMsgs.ttcn                                                                            
patching file MTC/MTC_Component.ttcn                                                                                 
patching file MTC/MTC_Main.ttcn                                                                                      
patching file NasEmulation/NasEmu_AspTypes.ttcn                                                                      
patching file common/CommonIratDefs.ttcn                                                                             
patching file common/UpperTesterDefs.ttcn 


created bin and started compilation with ../install.sh




First of all, the compiler tries to warn you if it estimates the translation port will not work as expected:
:
 MTC_Main.ttcn:62.3-168.3: In function definition `f_MTC_ConnectPTCs':                                                                      
  MTC_Main.ttcn:76.5-27: In map statement:                                                                                                  
   MTC_Main.ttcn:76.5-27: note: This mapping is not done in translation mode, because the second endpoint is unknown     
:
 SRSLTE_RLC_Test.ttcn:59.3-80.3: In testcase definition `TC_7_2_2_1':                                                                       
  SRSLTE_RLC_Test.ttcn:71.5-27: In map statement:                                                                                           
   SRSLTE_RLC_Test.ttcn:71.5-27: note: This mapping is not done in translation mode    



( I am compiling with latest Titan from source, please make sure you do the same)

see https://www.eclipse.org/forums/index.php/t/1091899/

By default a translation port is mapped to the empty skeleton/direct port if the system clause, config file etc, are not consistent; in such a situation the compiler issues a note as it cannot be certain if this is intentional or not.

So please check this first.



I'm not sure what you mean by SYSTEM being nested in MTC, but it does not sound right.

The system component represents the system under test and it mirrors the ports of all the components, see figure;

index.php/fa/32620/0/

Here you need to map MTC:portA to system:sysportA, PTC1:portB to system:sysportB etc.


The component ports are abstract ports , while the system ports are the matching physical ports .

For simple ports both component ports and system ports are of the same type (e.g. UDPasp_PT) and system component declaration can be forgotten (though I prefer to do it for clarity) as the compiler will assume it.

For translation ports the component ports are of one type,

in your case IPL4_MTC_System_Ut_PT
// Translation port to map between ETSI messages and IUT
type port IPL4_MTC_System_Ut_PT message map to IPL4asp_PT //translation port
{
 out
     UT_SYSTEM_REQ to ASP_Send with f_enc_UT_SYSTEM_REQ_translation()
 in
     UT_COMMON_CNF from ASP_RecvFrom with f_dec_UT_COMMON_CNF_translation(),
     ASP_Event
}


and system ports are of the type to which the upper port is mapped
(in your case IPL4asp_PT)

and declaring a system component is compulsory else translation will not work (the port will bind to an empty internal skeleton)

Also every function, test case etc. which refers to mapping the translation ports will have to have the right 'runs on' and 'system' clause, or , again, translation will not work.

I know the translation ports are a bit fussy, but they offer the huge advantage of reusing a lower layer port for higher level protocols.



I hope this made it a bit clearer.

Best regards

Elemer

  • Attachment: system.png
    (Size: 16.27KB, Downloaded 349 times)

[Updated on: Tue, 17 April 2018 13:27]

Report message to a moderator

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785852 is a reply to message #1785587] Fri, 20 April 2018 15:55 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey Elemer,

thanks again for your help. I've updated my titan and now use a version compiled from source. I am not sure if the old version I was using also had the note below.

MTC_Main.ttcn:76.5-27: note: This mapping is not done in translation mode, because the second endpoint is unknown


Anyway, I followed from there and eventually found that the "runs on MTC system SYSTEM" was missing in the function that set up the mapping between MTC and system. Thanks again for that clarification. I am now able to receive the UpperTester commands at my DUT and also make use of the JSON conversion which is great.

However, there is another open issue that I am looking at right now and that is related to the connectionId (or association ;-). See the post below, i.e.
function f_enc_UT_SYSTEM_REQ_translation(in UT_SYSTEM_REQ pl_in, out ASP_Send pl_out) //return integer
{
  log("f_enc_UT_SYSTEM_REQ_translation");
  pl_out.connId := -1; // will not work
  pl_out.msg := enc_UT_SYSTEM_REQ(pl_in);
  pl_out.proto := omit; 
  
  port.setstate(0);
}with {extension "prototype(fast)" }


I understand that -1 will not work but how am I supposed to pass the return value of the "f_Test_openConnection_MTC" to the encoding function of the translation port?

Best regards
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785854 is a reply to message #1785852] Fri, 20 April 2018 16:33 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

the translation ports have their own separate variable space, disjunct from the variable space of the components, so a small trick is needed to smuggle the connId value into that ; please check this post:


https://www.eclipse.org/forums/index.php/t/1092290/

I'll refer to that below.

First , you add integer to the out message list of the translation port and a port variable in which you can store the connection ID:

//*************************************************************************
type port HTTP2Port  message map to IPL4asp_PT {
//*************************************************************************
  out 	        HTTP2_Frames	to	ASP_Send     with f_enc_HTTP2_Frames_to_ASPSend(),
  		octetstring	to	ASP_Send     with f_enc_octetstring_to_ASPSend(),
  		integer       	to      ASP_Send     with f_set_connId() <------------------------------------                                                  
 in 	        HTTP2_Frame    from 	ASP_RecvFrom with f_dec_ASPRecvFrom_to_HTTP2_Frame(),
  		ASP_Event      from	ASP_Event    with  f_discardASPEvent()


  var HTTP2_Frame v_HTTP2_Frame;	
  var integer v_cid;                                                     <------------------------------------
  var HTTP2_decoder_error_descr v_err;

} with {extension "internal" }



the translation function associated with the integer type will store the connection Id passed as an incoming parameter , and will produce no output:


//*************************************************************************
function f_set_connId(in integer p_in, out ASP_Send  p_out) port HTTP2Port
//*************************************************************************
{
  v_cid:=p_in; //save connection Id
  port.setstate(4); //discard output
}with {extension "prototype(fast)"}



Now all that needs to be done is to send the connection Id as a message to the port
after calling f_IPL4_connect:


vl_result :=IPL4asp_User_CtrlFunct.f_IPL4_connect( http2_port, tsp_hostname, 50050,"",0, -1, {tcp := {} }, {} );
  log("connect result",vl_result)
  if (not(ispresent(vl_result.connId)))  {  log("Could not connect");   stop;  } 
  v_cid:=vl_result.connId ;
  http2_port.send(v_cid);// send connId to the port


After this, protocol messages can be translated.

Also, we have added statefulness as a non-standard extension to the translation port ( subject of a future post)
which means that the whole state machine can be resolved by translation;
In this case one may want to invoke f_IPL4_connect from within the translation port and track the connection Id (or Ids) with port variables.

I hope this helps

Best regards
Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785933 is a reply to message #1785854] Mon, 23 April 2018 09:35 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Thanks Elemer! That works nicely.
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1785985 is a reply to message #1785933] Mon, 23 April 2018 20:06 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi again,

I am currently in the process of converting all the system ports defined in MTC_Component.ttcn that are not UTRAN, GERAN, CDMA2K into translation ports to connect to the DUT over TCP. I started with the Ut port (MTC_System_Ut) which works fine up to the point where I transmit the first JSON converted message (POWER_OFF) to the DUT and receive the JSON encoded result from the UE. For some reason, however, after receiving the confirmation from the DUT the E_Ut port is closed unexpectedly and the whole test is stopped (see long log below).

On the console I am also getting a
Dynamic test case error: Message cannot be sent to system on internal port SYS.
which may or may not be the cause for the error. Unfortunately, I couldn't really find where this transmission on port SYS is made but my question is if it is a) the shutdown is really related to that error and b) if I definitely need to have all translation ports in place or if I can somehow develop with a more incremental approach and use internal ports until I really need the functionality on the DUT side without breaking something?

Thanks
Andre


21:52:17.264716 - TTCN-3 Main Test Component started on andre-xps13. Version: CRL 113 200/6 R4A.
21:52:17.264775 - TTCN Logger v2.2 options: TimeStampFormat:=Time; LogEntityName:=No; LogEventTypes:=No; SourceInfoFormat:=Stack; *.FileMask:=LOG_ALL; *.ConsoleMask:=ERROR | TESTCASE | STATISTICS_VERDICT | STATISTICS_UNQUALIFIED; LogFileSize:=0; LogFileNumber:=1; DiskFullAction:=Error
21:52:17.264839 - Connected to MC.
21:52:17.265098 - Executing control part of module SRSLTE_RLC_Test.
21:52:17.265188 SRSLTE_RLC_Test.ttcn:121 Execution of control part in module SRSLTE_RLC_Test started.
21:52:17.265224 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Test case TC_7_2_2_1 started.
21:52:17.265254 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Initializing variables, timers and ports of component type MTC_Component.MTC inside testcase TC_7_2_2_1.
21:52:17.265286 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Port Ut was started.
21:52:17.265304 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Port E_Ut was started.
21:52:17.265313 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Port U_Ut was started.
21:52:17.265321 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Port G_Ut was started.
21:52:17.265329 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Port CDMA2000_Ut was started.
21:52:17.265337 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:97 Component type MTC_Component.MTC was initialized.
21:52:17.265346 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:100 Creating new alive PTC with component type EUTRA_Component.EUTRA_PTC.
21:52:17.265843 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:100 PTC was created. Component reference: 3, alive: yes, type: EUTRA_Component.EUTRA_PTC.
21:52:17.265860 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:107->MTC_Main.ttcn:40 Connecting to DUT
21:52:17.265876 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:77 Port Ut was started.
21:52:17.265885 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:77 Mapping port mtc:Ut to system:Ut.
21:52:17.265919 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:77 Port Ut was mapped to system:Ut.
21:52:17.265943 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:77 Port Ut was mapped to system:Ut.
21:52:17.265983 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:77 Map operation of mtc:Ut to system:Ut finished.
21:52:17.266007 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:85 Creating new alive PTC with component type NasEmu_Component.NASEMU_PTC.
21:52:17.266394 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:85 PTC was created. Component reference: 4, alive: yes, type: NasEmu_Component.NASEMU_PTC.
21:52:17.266408 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:90 Connecting ports 3:UT and mtc:E_Ut.
21:52:17.266507 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:90 Port E_Ut is waiting for connection from 3:UT on UNIX pathname /tmp/ttcn3-portconn-c2bf511.
21:52:17.266566 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:90 Port E_Ut has accepted the connection from 3:UT.
21:52:17.266583 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:90 Connect operation on 3:UT and mtc:E_Ut finished.
21:52:17.266594 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:93 Connecting ports 3:NASCTRL and 4:CTRL.
21:52:17.266704 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:93 Connect operation on 3:NASCTRL and 4:CTRL finished.
21:52:17.266717 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:94 Connecting ports 3:SRB and 4:TC_SRB.
21:52:17.266822 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:94 Connect operation on 3:SRB and 4:TC_SRB finished.
21:52:17.266833 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:97 Mapping port 3:SYS to system:E_SYS.
21:52:17.266882 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:97 Map operation of 3:SYS to system:E_SYS finished.
21:52:17.266896 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:108 Starting function f_NASEMU_MainLoop(false) on component 4.
21:52:17.266934 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:108 Function was started.
21:52:17.266950 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:45 Creating new alive PTC with component type IP_PTC_Component.IP_PTC.
21:52:17.267336 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:45 PTC was created. Component reference: 5, alive: yes, type: IP_PTC_Component.IP_PTC.
21:52:17.267356 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:48 Connecting ports 3:IP and 5:EUTRA_CTRL.
21:52:17.267485 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:48 Connect operation on 3:IP and 5:EUTRA_CTRL finished.
21:52:17.267501 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:57 Mapping port 5:IP_CTRL to system:IP_CTRL.
21:52:17.267554 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:57 Map operation of 5:IP_CTRL to system:IP_CTRL finished.
21:52:17.267565 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:58 Mapping port 5:IP_SOCK to system:IP_SOCK.
21:52:17.267612 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:58 Map operation of 5:IP_SOCK to system:IP_SOCK finished.
21:52:17.267627 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:60 Starting function f_IP_PTC_MainLoop() on component 5.
21:52:17.267657 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:109->MTC_Main.ttcn:172->MTC_Main.ttcn:60 Function was started.
21:52:17.267744 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:111->SRSLTE_RLC_Test.ttcn:54 { errorCode := omit, connId := 1, os_error_code := omit, os_error_text := omit }
21:52:17.267771 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:111->SRSLTE_RLC_Test.ttcn:61 Sent on Ut to system integer : 1
21:52:17.267783 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:111->SRSLTE_RLC_Test.ttcn:61 The state of the Ut port was changed by a setstate operation to unset. Information: by test environment.
21:52:17.267795 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:111->SRSLTE_RLC_Test.ttcn:61->IPL4_MTC_SYSTEM_Ut_Definitions.ttcn:47 The state of the Ut port was changed by a setstate operation to discarded.
21:52:17.267808 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:115 Starting function f_TC_7_2_2_1_EUTRA() on component 3.
21:52:17.267841 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:115 Function was started.
21:52:17.267851 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:116 Start timer t_GuardTimer: 5 s
21:52:17.267893 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:361 Sent on Ut to system @UpperTesterDefs.UT_SYSTEM_REQ : { Cmd := { MMI := { Cmd := "POWER_OFF", ParameterList := omit } }, CnfRequired := true }
21:52:17.267905 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:361 The state of the Ut port was changed by a setstate operation to unset. Information: by test environment.
21:52:17.267917 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:361->IPL4_MTC_SYSTEM_Ut_Definitions.ttcn:23 f_enc_UT_SYSTEM_REQ_translation
21:52:17.267936 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:361->IPL4_MTC_SYSTEM_Ut_Definitions.ttcn:28 The state of the Ut port was changed by a setstate operation to translated.
21:52:17.267954 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:361 Outgoing message was mapped to @IPL4asp_Types.ASP_Send : { connId := 1, proto := omit, msg := '7B22436D64223A7B224D4D49223A7B22436D64223A22504F5745525F4F4646227D7D2C22436E665265717569726564223A747275657D'O ("{\"Cmd\":{\"MMI\":{\"Cmd\":\"POWER_OFF\"}},\"CnfRequired\":true}") }
21:52:17.268068 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362 Message enqueued on Ut from system @IPL4asp_Types.ASP_RecvFrom : { connId := 1, remName := "127.0.0.1", remPort := 2222, locName := "127.0.0.1", locPort := 2223, proto := { tcp := { } }, userData := 0, msg := '7B22526573756C74223A747275657D'O ("{\"Result\":true}") } id 1
21:52:17.268118 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362 The state of the Ut port was changed by a setstate operation to unset. Information: by test environment.
21:52:17.268152 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362->IPL4_MTC_SYSTEM_Ut_Definitions.ttcn:34 f_dec_UT_COMMON_CNF_translation
21:52:17.268184 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362->IPL4_MTC_SYSTEM_Ut_Definitions.ttcn:41 The state of the Ut port was changed by a setstate operation to translated.
21:52:17.268216 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362 Incoming message was mapped to @UpperTesterDefs.UT_COMMON_CNF : { Result := true, ResultString := omit } id 1
21:52:17.268249 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362 Receive operation on port Ut succeeded, message from system(): @UpperTesterDefs.UT_COMMON_CNF : { Result := true, ResultString := omit } id 1
21:52:17.268280 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:230->MTC_UpperTester.ttcn:362 Message with id 1 was extracted from the queue of Ut.
21:52:17.268311 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:232 power off over
21:52:17.272609 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:236 Connection of port E_Ut to 3:UT was closed unexpectedly by the peer.
21:52:17.272631 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:236 Port E_Ut was disconnected from 3:UT.
21:52:17.272661 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:237->MTC_Main.ttcn:193 any component.killed
21:52:17.272672 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:237->MTC_Main.ttcn:194 Killing all components.
21:52:17.273090 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:237->MTC_Main.ttcn:194 All components were killed.
21:52:17.273109 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118->MTC_Main.ttcn:237->MTC_Main.ttcn:195 Stopping test component execution.
21:52:17.273246 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Test case TC_7_2_2_1 was stopped.
21:52:17.273262 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Terminating component type MTC_Component.MTC.
21:52:17.273275 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Removing unterminated mapping between port Ut and system:Ut.
21:52:17.273289 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port Ut was unmapped from system:Ut.
21:52:17.273388 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port Ut was stopped.
21:52:17.273403 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port E_Ut was stopped.
21:52:17.273413 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port U_Ut was stopped.
21:52:17.273422 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port G_Ut was stopped.
21:52:17.273432 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port CDMA2000_Ut was stopped.
21:52:17.273441 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Removing unterminated mapping between port Ut and system:Ut.
21:52:17.273471 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port Ut was unmapped from system:Ut.
21:52:17.273489 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Port Ut was stopped.
21:52:17.273500 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Component type MTC_Component.MTC was shut down inside testcase TC_7_2_2_1.
21:52:17.273511 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Waiting for PTCs to finish.
21:52:17.273553 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Setting final verdict of the test case.
21:52:17.273572 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Local verdict of MTC: none
21:52:17.273585 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Local verdict of PTC with component reference 3: error (none -> error)
21:52:17.273595 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Local verdict of PTC with component reference 4: none (error -> error)
21:52:17.273605 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Local verdict of PTC with component reference 5: none (error -> error)
21:52:17.273617 SRSLTE_RLC_Test.ttcn:125->SRSLTE_RLC_Test.ttcn:118 Test case TC_7_2_2_1 finished. Verdict: error
21:52:17.273637 SRSLTE_RLC_Test.ttcn:125 Execution of control part in module SRSLTE_RLC_Test finished.
21:52:17.274682 - Verdict statistics: 0 none (0.00 %), 0 pass (0.00 %), 0 inconc (0.00 %), 0 fail (0.00 %), 1 error (100.00 %).
21:52:17.274785 - Test execution summary: 1 test case was executed. Overall verdict: error
21:52:17.274823 - Exit was requested from MC. Terminating MTC.

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786041 is a reply to message #1785985] Tue, 24 April 2018 16:10 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi,

please ignore my somewhat messy previous post. But I've now converted all system ports into translation ports but am facing an issue in configuring them again. I am unsure how and especially where to call the openConnection for the IPL4 port. The port that is working so far (IPL4_MTC_System_Ut) has the "runs on MTC system SYSTEM" flag and I can call the connect function from within the testcase definition. All other ports, however, like the SYS, SYSIND, etc are either on the EUTRA_PTC, on the NASEMU_PTC or on the IP_PTC. So I can't directly execute function on those PTCs from the testcase. What's best practice here to achieve the configuration? Earlier it was mentioned that in order for the translation ports to work it is essential to have the "system SYSTEM" clause in place as well which isn't the case for any of the PTCs, so would I need to define that for those?

Thanks
Andre

Update:
Just updated the public repo to better replicate the issue.

[Updated on: Tue, 24 April 2018 16:19]

Report message to a moderator

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786063 is a reply to message #1786041] Wed, 25 April 2018 06:00 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,


If you have only one connection/association per port at one time, which I think might be your case , then you might not need to use the f_IPL4_connect ;


Let me repeat an earlier entry:

"
If you expect to have only one UDP ( or TCP) channel along the duration of your test case, you can use the following simplification:
the connection can be controlled not only from f_openConnection, but directly from the map operation , meaning that when mapped, the port will open automatically a connection with parameters taken from the config file;

if , on top of that , lazy_conn_id_handling is set to yes (and only one comms channel in the system, which can be unequivocally referred to) ,
then the user does not have to care about the real value of the connection id , the dummy value -1 can be used instead.

This means that you can skip the f_openConnectionFunction but have to use in the config file something like:


*.portName.defaultListeningPort				:= "0"  
*.portName.map_behavior					:= "connect"  
*.portName.RemotePort						:= "666"			 // SUT - Port
*.portName.RemoteHost						:= "127.0.0.1"   // SUT - IP    
*.portName.lazy_conn_id_handling			       := "yes"  
*.portName.debug                                                     := "yes" //or "no"
*.mccPort.map_protocol                                           := "udp"



For obvious reasons this setup can handle one connection only ; with f_connect() , f_close() etc. , any number of connections can be opened or closed flexibly at any moment.
"

In this case, connect is called implicitly when the port is mapped.
So maybe this is the way to go in your case. Try it with one port first to see how it works.



Otherwise you will have to add f_IPL4_connect to the appropriate sections of the functions running on PTC's which might force you to re-edit the code
-which is coming from elsewhere -anytime it changes.

Please let me now if this helps.

Best regards
Elemer



Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786154 is a reply to message #1786063] Thu, 26 April 2018 08:39 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

yes, you are right, I think one association per port at a time is enough in my case which allows me to use the lazy connection handling. I actually tried that before but now looking at the logs again, I don't think that's the main issue I am having currently. Because in theory, even without the port being connected, I should see the log entry I put in the translation port sending function, i.e. f_enc_SYSTEM_CTRL_REQ_translation(), which I don't. I see the message being sent on the port but the translation port is never called to transmit it. And I think the reason is that another component isn't started up correctly and hence the entire execution is stopped. I've attached the entire logs of the execution but here is the snippet that I think causes the issue. Unfortunately, it doesn't tell much about what is actually going wrong. I also put various log calls before and after the functions that are mentioned in the log below but they don't seem to appear in the log after all. Any idea what might be wrong here in the NasEmu or IP_PTC?

10:28:29.801531 - Port IP_CTRL was mapped to system:IP_CTRL.
10:28:29.801592 - Port IP_SOCK was mapped to system:IP_SOCK.
10:28:29.801657 - Starting function f_IP_PTC_MainLoop().
10:28:29.801664 IP_PTC_Main.ttcn:288 f_IP_PTC_Ma10:28:34.803912 NasEmu.ttcn:685 Stop was requested from MC.
10:28:34.804070 NasEmu.ttcn:685 Stopping test component execution.
10:28:34.804857 - Function f_NASEMU_MainLoop was stopped. PTC remains alive and is waiting for next start.


Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786163 is a reply to message #1786154] Thu, 26 April 2018 10:36 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

the logs and the code in https://github.com/andrepuschmann/ttcn3_rlc don't seem to be in sync;

could you please update the code?

Also I 'd recommend to leave file naming to Titan:
change

LogFile := "../log/RLC_Test-%n.log"

to

#LogFile := "../log/RLC_Test-%n.log"


and set

LogSourceInfo := Yes

(Not stack)


and FileMask


FileMask := LOG_ALL | TTCN_MATCHING | TTCN_DEBUG

(Log_all does not cover matching and debug)

and upload the logs again


BR

Elemer




Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786171 is a reply to message #1786163] Thu, 26 April 2018 12:38 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi,

updated the code and followed your suggestions. In order to check if the lazy connection handling is actually working I tried it with the MTC_System_Ut port as well (for which I have the openConnection function but commented it out for this test) and it appears that its not working for that port either. I guess there is something wrong in the config but I tried many combinations.

14:27:48.539096 MTC_UpperTester.ttcn:360 Outgoing message was mapped to @IPL4asp_Types.ASP_Send : { connId := -1, proto := omit, msg := '7B22436D64223A7B224D4D49223A7B22436D64223A22504F5745525F4F4646227D7D2C22436E665265717569726564223A747275657D'O ("{\"Cmd\":{\"MMI\":{\"Cmd\":\"POWER_OFF\"}},\"CnfRequired\":true}") }
14:27:48.539113 MTC_UpperTester.ttcn:360 Ut: IPL4asp__PT_PROVIDER::outgoing_send: ASP Send: enter
14:27:48.539125 MTC_UpperTester.ttcn:360 Ut: IPL4asp__PT_PROVIDER::outgoing_send_core: ASP Send: enter
14:27:48.539131 MTC_UpperTester.ttcn:360 Ut: IPL4asp__PT_PROVIDER::getAndCheckSockType: invalid connId: -1
14:27:48.539136 MTC_UpperTester.ttcn:360 Ut: IPL4asp__PT_PROVIDER::outgoing_send_core: ASP Send: INVALID INPUT PARAMETER


However, for the EUTRA_PTC which does a send on SYS, it still doens't call the translation port.

14:27:48.542996 EUTRA_ConfigurationSteps.ttcn:76 Sent on SYS to system @EUTRA_ASP_TypeDefs.SYSTEM_CTRL_REQ :  { ...}


I've attached the corresponding logs as well.

Thanks again
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786175 is a reply to message #1786171] Thu, 26 April 2018 13:26 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,


it's visible form the log that connect on map does not happen:
14:27:48.536840 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
14:27:48.536851 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: tcp)
14:27:48.536857 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: defaultListeningPort, value: 0)
14:27:48.536861 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_behavior, value: connect)
14:27:48.536866 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemotePort, value: 2222)
14:27:48.536871 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemoteHost, value: 127.0.0.1)
14:27:48.536876 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: lazy_conn_id_handling, value: yes)
14:27:48.536881 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
14:27:48.536885 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
14:27:48.536889 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: tcp)
14:27:48.536895 MTC_Main.ttcn:96 Ut: IPL4asp__PT_PROVIDER::user_map(Ut): enter
14:27:48.536899 MTC_Main.ttcn:96 Port Ut was mapped to system:Ut.


You should see something like:


2018/Apr/17 13:43:00.347519 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
2018/Apr/17 13:43:00.347538 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: tcp)
2018/Apr/17 13:43:00.347552 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: tcp)
2018/Apr/17 13:43:00.347569 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::user_map(mcaPort): enter
2018/Apr/17 13:43:00.347627 PORTEVENT OneM2M_Functions.ttcn:37(function:f_cf01Up) entering f__IPL4__PROVIDER__connect: :0 -> 203.253.128.161:7579 / TCP
2018/Apr/17 13:43:00.347656 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: enter
2018/Apr/17 13:43:00.347705 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: create new socket: :0 -> 203.253.128.161:7579
2018/Apr/17 13:43:00.347724 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: SetLocalSockAddr: locName:  loc_port 0 def_loc_host 0.0.0.0, add_family AF_INET
2018/Apr/17 13:43:00.347738 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: use default host: 0.0.0.0:0
2018/Apr/17 13:43:00.347765 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::setOptions: enter, number of options: 0
2018/Apr/17 13:43:00.347779 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::setOptions: sock: 7
2018/Apr/17 13:43:00.347799 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::setOptions: Socket option REUSEADDR on socket 7 is set to: 1
2018/Apr/17 13:43:00.347813 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::setOptions: leave
2018/Apr/17 13:43:00.347835 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: sock: 7
2018/Apr/17 13:43:00.347909 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: error: Operation now in progress
2018/Apr/17 13:43:00.347931 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER: ConnAdd enter: type: 2, ssl_tls_type: 0, sock: 7, parentIx: -1
2018/Apr/17 13:43:00.347953 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::ConnAdd: new sockListSize: 16
2018/Apr/17 13:43:00.347979 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::ConnAdd: connId: 1
2018/Apr/17 13:43:00.348006 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::ConnAdd: connId: set ssl options for connId : 1
2018/Apr/17 13:43:00.348025 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::set_ssl_supp_option: set SSL options
2018/Apr/17 13:43:00.348079 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::ConnAdd: getpeername failed: Transport endpoint is not connected
2018/Apr/17 13:43:00.348104 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: IPL4asp__PT_PROVIDER::ConnAdd: leave: sockListCnt: 1
2018/Apr/17 13:43:00.348119 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: EAGAIN: waiting in poll: fd 7   connId: 1
2018/Apr/17 13:43:00.660474 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: EAGAIN: poll returned: 1
2018/Apr/17 13:43:00.660548 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: EAGAIN: revents: 0x0004
2018/Apr/17 13:43:00.660564 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: EAGAIN: writable
2018/Apr/17 13:43:00.660594 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: Probing connection: getsockopt returned: 0, connection result code: 0
2018/Apr/17 13:43:00.660610 DEBUG OneM2M_Functions.ttcn:37(function:f_cf01Up) mcaPort: f__IPL4__PROVIDER__connect: leave
2018/Apr/17 13:43:00.660631 PORTEVENT OneM2M_Functions.ttcn:37(function:f_cf01Up) Port mcaPort was mapped to system:mcaPort.


as taken from a similar log;

now, as discussed before, all functions, testcases etc. where mapping is done must have appropriate runs on and system clauses,
so I'm suspecting that the missing system clause of
  function f_MTC_ConnectPTCs(EUTRA_PTC p_Eutra,
                             UTRAN_PTC p_Utran,
                             GERAN_PTC p_Geran,
                             CDMA2000_PTC p_Cdma2000) runs on MTC

could be the reason of the problem

Could you please test this hypothesis?

BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786179 is a reply to message #1786175] Thu, 26 April 2018 14:00 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey,

thanks for the hint, I actually had the debug set at the end of the config and was only seeing part of the output in the log. Just checked the below function in MTC_Main.ttcn and that is exactly where I already put the "runs on MTC system SYSTEM" clause. See below.

  function f_MTC_ConnectPTCs(EUTRA_PTC p_Eutra,
                             UTRAN_PTC p_Utran,
                             GERAN_PTC p_Geran,
                             CDMA2000_PTC p_Cdma2000) runs on MTC system SYSTEM


And it works ok when the openConnection is called explicitly. But I've now idea why the connect isn't called when using lazy handling.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786182 is a reply to message #1786179] Thu, 26 April 2018 14:33 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

just so I understand correctly:

-with f_connect it works but with map it does not , amiright?

BR
Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786185 is a reply to message #1786182] Thu, 26 April 2018 15:04 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
That's right. In the current version the "f_Test_openConnection_MTC(MTC_PT_connectionParams, -1);" in "testcase TC_7_2_2_1()" is commented out and the mapping doesn't work. If I uncomment it works.
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786186 is a reply to message #1786182] Thu, 26 April 2018 15:05 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

it appears that for some reason you are using an old version of IPL4 test port
R18N
// Prodnr: CNL 113 531
// Updated: 2013-08-27

the current version being R30A;
This old version does not support connect on map.
could you try to update please?

Also the Socket-API and AbstractSocket while you are at it.


BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786188 is a reply to message #1786186] Thu, 26 April 2018 15:26 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Ah, very good catch. I was actually copying it from an apparently outdated example. Building now ..
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786204 is a reply to message #1786188] Thu, 26 April 2018 20:30 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi,

yes, the TestPort update did the trick for with the lazy connection handling. It is now working for the Ut port. However, the SYS port is still refusing to connect. I went through all function calls along the way where the SYS.send() is called and made sure it has the "runs on EUTRA_PTC system SYSTEM" clause attached. Any other idea what might be wrong?

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786227 is a reply to message #1786204] Fri, 27 April 2018 07:51 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,


if I'm not mistaken ,
mapping of 3:SYS to system:E_SYS is done in
  function f_MTC_ConnectDUT(EUTRA_PTC p_Eutra) runs on MTC
  {
    log("Connecting to DUT");

    vc_Components.Eutra := p_Eutra;
    
    map(vc_Components.Eutra:SYS,      system:E_SYS);
    map(vc_Components.Eutra:SYSIND,   system:E_SYSIND);
    map(vc_Components.Eutra:DRB,      system:E_DRB);
    //map(v_NASEMU_PTC:SYS_SRB,         system:E_SRB);
    
  }
  


as seen in the log

22:26:43.280991 MTC_Main.ttcn:40 Connecting to DUT
22:26:43.281000 MTC_Main.ttcn:44 Mapping port 3:SYS to system:E_SYS.
22:26:43.281066 MTC_Main.ttcn:44 Map operation of 3:SYS to system:E_SYS finished.
22:26:43.281082 MTC_Main.ttcn:45 Mapping port 3:SYSIND to system:E_SYSIND.
22:26:43.281137 MTC_Main.ttcn:45 Map operation of 3:SYSIND to system:E_SYSIND finished.
22:26:43.281152 MTC_Main.ttcn:46 Mapping port 3:DRB to system:E_DRB.
22:26:43.281206 MTC_Main.ttcn:46 Map operation of 3:DRB to system:E_DRB finished.
22:26:43.281225 SRSLTE_RLC_Test.ttcn:67 Starting function f_TC_7_2_2_1_EUTRA() on component 3.



and I see no system clause for f_MTC_ConnectDUT ;

where am I wrong here?

BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786228 is a reply to message #1786227] Fri, 27 April 2018 08:41 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Right. That was the problem. Thanks! Although defining the "system" clause on that particular function didn't work either (and I believe I've tried that before). But I've now moved the mapping to fl_EUTRA_Common_Init() and that did the trick. Thanks again for the help. I am wondering however, if that mapping process can somehow be traced better to ease debugging in such a case.
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786229 is a reply to message #1786228] Fri, 27 April 2018 08:56 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

probably yes, but please have in mind that this translation function in Titan , besides being a quite complex one, is relatively new and untested in real-life usage ; we are working on refining it though.
Hence we appreciate all feedback we get from users.

Best regards
Elemer

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786230 is a reply to message #1786229] Fri, 27 April 2018 09:57 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Great. We are happy to provide feedback and also the full implementation once it's working. I think the Osmocom folks are using them quite extensively as well.
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786420 is a reply to message #1786230] Thu, 03 May 2018 06:51 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

an update:

You wrote:
Although defining the "system" clause on that particular function didn't work either (and I believe I've tried that before). But I've now moved the mapping to fl_EUTRA_Common_Init() and that did the trick.


It appears that this is a fault, probably the same as described in

Bug 534266 - Cannot map translation ports on other components
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534266


As soon as it is solved, I'll let you know, maybe it's worth retesting.

Best regards
Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786719 is a reply to message #1786420] Wed, 09 May 2018 19:50 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

that bug you referenced does indeed sound like it is the same. Let me know when there is a new version available and I'll test it.

On a different node, I've now completed the basic skeleton of the DUT that implements all required ports of the system interface to communicate with the tester. So far, I've only used JSON to communicate between the TTCN3 side and my DUT which works fine so far, also the matching of the responses works fine.

What I am trying to do now is to extract actual PER encoded PDUs (for SIB1 for example) to feed them into the UE stack and I am wondering what the best way to achieve this. I do have the asn1c encoders for the BCCH_DL_SCH_Message_t for example. Now, I'd like to keep the JSON encoded version as well and send the binary representation alongside with it, if possible. I am wondering about best-practices here and what others use. One options would be to have another socket and send the ASN1-encode PDUs over that or to use the same socket but somehow concatenate the binary encoded and JSON-encoded data. I hope my question is somehow understandable.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786740 is a reply to message #1786719] Thu, 10 May 2018 12:09 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

not sure I understand all the subtext, but why not create a new record type say

type record Composite
{
universal charstring json,
octetstring per
}

which can carry both representations and then send that across the port. If the port is between components ,
this is straightforward, the structure can be sent as is, if it's external , a simple binary encoding can be applied .

Does this make sense?



BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786742 is a reply to message #1786740] Thu, 10 May 2018 14:18 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

yes, this is exactly what I am looking at, but since this message is going over the IPL4 port to the DUT, I need a way to also unpack the message on the DUT. I am looking at possible ways to do this at the moment. I am using RapidJSON on the DUT side to parse the incoming data. But since JSON is text-only without a native binary option its not straightforward and that's why I was trying to see what other do in that case.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786744 is a reply to message #1786740] Thu, 10 May 2018 14:25 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

yes, this is exactly what I am looking at, but since this message is going over the IPL4 port to the DUT, I need a way to also unpack the message on the DUT. I am looking at possible ways to do this at the moment. I am using RapidJSON on the DUT side to parse the incoming data. But since JSON is text-only without a native binary option its not straightforward and that's why I was trying to see what other do in that case.

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786745 is a reply to message #1786742] Thu, 10 May 2018 14:27 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

yes but you can use RAW to binary encode-decode this whole composite structure; I think this is the simplest.
see posts about RAW in this forum.

BR

Elemer




Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1786762 is a reply to message #1786745] Thu, 10 May 2018 18:51 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

to ease the job of the RAW codec, you can add length info as below:
type record Composite
{
integer                           jsonLength,
universal  charstring   json,
integer                           perLength,
octetstring                    per 
}


so it's like a (Type)LengthValue protocol; the length info can be filled in by the RAW codec automatically at encoding
and at decoding it helps to find the boundaries between fields.

BR

Elemer
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787061 is a reply to message #1786762] Fri, 18 May 2018 07:59 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

fix for the aforementioned problem
Bug 534266 - Cannot map translation ports on other components
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534266

has been added to source, If you wish you may test it.

Also please take a look into

Porting 3ggp test suites to Titan
https://www.eclipse.org/forums/index.php/t/1093289/

as it may be relevant for you.


Best regards
Elemer

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787178 is a reply to message #1787061] Mon, 21 May 2018 11:07 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hey Elemer,

thanks for the update. I didn't test the translation port initialization yet, but will do soon. Basically what is now supposed to work is the port auto initialization without having to put the "runs on" clause on every component, right?

Also thanks for the 3gpp testsuite porting guide. Looking forward to the EUTRA part ;-) Btw. we've also made some more progress on our side and are now able to establish a RRC connection with the DUT. There is still a bit of work to do though ;-)

During development I noticed a few things that I don't know are bugs or I am just unable to do. First is to define a "record of" in a RAW encoded type. The code below works fine but as soon as I use a variable length record of
MsgElement's inside Composite, the encoder would work anymore.

type record MsgElement
{
  integer     len,
  octetstring payload
} with {
  variant (len) "LENGTHTO(payload)";
  variant (len) "FIELDLENGTH(16)";
  variant (len) "BYTEORDER(last)";
  variant "PADDING(yes)";
}

//type record of tb MsgElement;

type record Composite
{
  MsgElement  json,
  MsgElement  tb1 optional,
  MsgElement  tb2 optional,
  MsgElement  tb3 optional
} with {
  variant "";
}


The other issue is with the auto PER encoder which seems to have changed from only supporting octetstring as input/output in earlier version to now only supporting bitstrings. Is there a way to use octetsstrings again as this would avoid a lot of bit2oct any vice-verse throughput my code?

Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787235 is a reply to message #1787178] Tue, 22 May 2018 15:27 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,
regarding the RAW codec:

the problem arises from the optional fields:

it's impossible to tell when an optional field has been omitted; to deal with that, you need to add another field (for each optional field ) that indicates
presence or absence.

However, this should work :
type record Composite
{
  MsgElement  json,
  MsgElement  tb1,
  MsgElement  tb2,
  MsgElement  tb3
} with {
  variant "";
}


I don't think invoking external PER changed ; can you give me an example?
if you invoke it explicitly , declaring the external function , than you can decide to declare it (and define it ) with octetstrings or bitstrings.
if you invoke it implicitly, via encvalue/decvalue, then only bitstring can be used, but that did not change.


BR

Elemer








Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787567 is a reply to message #1787235] Tue, 29 May 2018 08:55 Go to previous messageGo to next message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi Elemer,

I've tried the PER encoding again and it seems like the compiler doesn't like the octetstring, as soon as I define:

  // encoder for DL-SCH
  external function enc_BCCH_DL_SCH_PDU( in BCCH_DL_SCH_Message pdu) return octetstring
    with { extension "prototype(convert) encode(PER)" };  


The compiler says this:

EUTRA_Types.ttcn: In TTCN-3 module `EUTRA_Types':
 EUTRA_Types.ttcn:16.3-87: In external function definition `enc_BCCH_DL_SCH_PDU':
  EUTRA_Types.ttcn:16.77-87: error: The output type of PER encoding should be `bitstring' instead of `octetstring'



Thanks
Andre
Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787615 is a reply to message #1787567] Wed, 30 May 2018 06:14 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Andre,

sorry , I was mistaken; indeed, external functions for PER have to be declared with bitstring input/output:

external function fx_enc_CAM (in CAM pdu) return bitstring
    with {extension "prototype(convert) encode(PER)"}


however you can declare a wrapper to use octetstring instead:
function my_own_fx_enc_CAM(in CAM pdu )  return octetstring
{
return  bit2oct(fx_enc_CAM(pdu))
}


and use that.

I hope this helps


BR

Elemer

[Updated on: Wed, 30 May 2018 06:14]

Report message to a moderator

Re: Encoding function for 3GPP RLC/PDCP PDUs [message #1787627 is a reply to message #1787615] Wed, 30 May 2018 09:46 Go to previous message
Andre Puschmann is currently offline Andre PuschmannFriend
Messages: 48
Registered: March 2018
Member
Hi,

thanks for the clarification. I was aware of the helper method and I use it often in the TTCN3 world. The "ugliness" is more in the C++ codec function where the input in bitstring needs to be prepared for the asn1c coder which uses a char array. But it's fine, because I just realized that even if it was in OCTETSTRING it still woundn't be flat in memory and I would need the conversion to char array.

Thanks
Andre
Previous Topic:State of the Osmocom TTCN-3 Test Suites
Next Topic:Eclipse Titan project page doesn't list 6.3.1 and 6.4.0 releases
Goto Forum:
  


Current Time: Fri Sep 21 16:22:46 GMT 2018

Powered by FUDForum. Page generated in 0.05077 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top