Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Porting 3gpp test suites to Titan
Porting 3gpp test suites to Titan [message #1787059] Fri, 18 May 2018 07:55
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Dear all,

we will examine below the portability of 3gpp-published test suites to Titan.
But before getting started, let me reveal some problems one may encounter with certain Titan releases when
compiling test suites containing large ASN.1 files.

Roughly a year ago, post 6.1.0 release, code to support concatenation of templates was added to Titan:

Bug 512878 - Concatenation for templates
https://bugs.eclipse.org/bugs/show_bug.cgi?id=512878


Unfortunately this had the side effect of dramatically slowing down compilation of some ASN.1 files and this was not caught by our CI cycle.
Now 3gpp test suites are building upon such large files, one being especially large, the UTRAN_RRC_ASN1_Definitions.asn , of 1.46 Megabytes in source.
With this file the slowdown is particularly observable, probably grinding compilation to a halt.
Even if the slicing feature of the compiler ( -U 'number) ' is used, this file will cause problems.

The problem persisted throughout 6.2.0 and 6.3.0 but we caught it before releasing 6.4.0 so the latest source code and the to-be-released 6.4.0 already contain the fix for the problem.
For this exercise I have used a Titan built from the latest source, release candidate for 6.4.0.

The referring bug report is here:


Bug 534678 - Performance issues caused by template concatenation feature
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534678

and the github commit , for those interested in details, here:

Changed handling of optional fields in template concatenation to improve performance (bug 534678)
https://github.com/eclipse/titan.core/commit/736c4bdaa0eaa2709e8292746e2456117d08efdf

The takeaway from this is that for 3gpp test suites one should use either 6.1.0 or , if he/she needs the latest features, 6.4.0 ,
and should avoid 6.2.0 and 6.3.0. However, given the presence of large ASN.1 files we keep recommending using slicing the files -as exemplified below-
so one can benefit from compiling in parallel a higher number of smaller files. This will also have a beneficial effect on memory consumption which will prove to be
a scarce resource when compiling these suites.

For other test suites this slowdown may or may not be observable , but will probably stay under the observation threshold.

All right then, now to the point.

3gpp published test suites are available here:

http://www.ttcn-3.org/index.php/downloads/publicts/publicts-3gpp

and today we will look into UTRA test suites:
http://www.ttcn-3.org/index.php/downloads/publicts/publicts-3gpp/78-3gpp-utra-ue-test-suite

The entire series is published here:
ftp://ftp.3gpp.org/Specs/archive/34_series/34.123-3/

and I have downloaded the latest one:
ftp://ftp.3gpp.org/Specs/archive/34_series/34.123-3/34123-3-e20.zip
dated 4/3/18

This package contains two independent suites, 34123-3-e20_TTCN3_UTRAN and 34123-3-e20_TTCN3_SSNITZ.


What can we expect based on our previous experience of porting ETSI test suites ?
(see posts in this forum)

Of course we will encounter the unholy trinity of: 1) test port declarations 2) codecs 3) external functions ,
that is unstandardised code that Titan expects to be supplied in form of external C++ code.

As before the aim is to make the test suite compilable and not executable.
Whoever wants to take this next step as well will have to add the external code mentioned before.


Let's start with 34123-3-e20_TTCN3_SSNITZ first ( see attached archive)


1. First we should generate a Makefile; here I recommend using Runtime 2 , the function test runtime, which , although is somewhat slower when compiling , is richer in features.
Also , code slicing is strongly recommended.

Here you have the significant lines in my Makefile:
# Flags for the C++ preprocessor (and makedepend as well):
CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include  -DTITAN_RUNTIME_2

# Flags for the TTCN-3 and ASN.1 compiler:
COMPILER_FLAGS = -L  -w  -R -U 8 -M -d

# Execution mode: (either ttcn3 or ttcn3-parallel)
TTCN3_LIB = ttcn3-rt2-parallel

with the meaning of switches:

 -M:             allow 'omit' in template value lists (legacy behavior)
 -d:             treat default fields as omit          
 -R:             use function test runtime (TITAN_RUNTIME_2)
 -L:             add source line info for logging
 -U none|type|'number':  select code splitting mode for the generated C++ code
 -w:             suppress warnings



Even if slicing is done in 8 parts, compilation can be done with less processors involved: make -j4 or even make -j2 or simply make.
Please bear in mind that if we engage a number of processors in parallel compilation , the amount of required memory will multiply as well , so make sure you have sufficient memory,
else you may end up with a surprise.



2. the next step we need to take is to add a dummy encoding instruction to the ComponentsType.ttcn:
  type set of Component  Components;     /* @status    APPROVED (POS, SSNITZ) */

  } // end of group SS_Asn_Entry

with {encode "Some_EncRule"};  //FIXME!!!

This dummy declaration and all other such with { encode "somethinghere"} declarations will have to be added substance later
by adding the appropriate external codecs.


3. All ports in all declarations will be turned internal ;

of course , eventually ports that are mapped to SUT will have to be re-qualified external and the pertinent test port code will have to be added.


4. External functions

I have replaced external function declarations with matching internal but dummy declarations:

CommonDefs.ttcn

 /* external */ function fx_KeyDerivationFunction(KDF_Type  p_KDF,
                                             bitstring p_Key, //@sic R5-155058 sic@
                                             octetstring p_String) return B256_Type {
                                             
                                             return '1111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000'B
                                             }; 
											 
											 
 /* external */ function fx_GetSystemTime(out Struct_tm_Type p_Struct_tm,    /* p_Struct_tm returns local system time;
                                                                         * C implementation:
                                                                         *         time_t v_Now = time(NULL);
                                                                         *         struct tm *v_Tm = localtime(&v_Now);
                                                                         */
                                     out integer p_TimezoneInfo)
                                     {};  											 




With these changes the suite will compile.


Let's move to 34123-3-e20_TTCN3_UTRAN then:


1. We can use the same Makefile settings:

# Flags for the C++ preprocessor (and makedepend as well):
CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include  -DTITAN_RUNTIME_2

# Flags for the TTCN-3 and ASN.1 compiler:
COMPILER_FLAGS = -L  -w  -R -U 8 -M -d

# Execution mode: (either ttcn3 or ttcn3-parallel)
TTCN3_LIB = ttcn3-rt2-parallel

2. Codecs will not give us a headache at this stage but of course will have to be added eventually.

3. All ports will have to be declared internal

4. External functions are to be replaced with dummies:

CommonDefs.ttcn

 /* external */ function fx_KeyDerivationFunction(KDF_Type  p_KDF,
                                             bitstring p_Key, //@sic R5-155058 sic@
                                             octetstring p_String) return B256_Type {
                                             
                                             return '1111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000'B
                                             }; 
											 
											 
 /* external */ function fx_GetSystemTime(out Struct_tm_Type p_Struct_tm,    /* p_Struct_tm returns local system time;
                                                                         * C implementation:
                                                                         *         time_t v_Now = time(NULL);
                                                                         *         struct tm *v_Tm = localtime(&v_Now);
                                                                         */
                                     out integer p_TimezoneInfo)
                                     {};  											 

									 

EUTRA_NB_CommonDefs.ttcn

 
  /*external*/  function fx_CalculateFCS32 (bitstring p_TMSI) return B32_Type {



return '11111111000000001111111100000000'B

};

EUTRA_NB_SecurityDefinitionsAndExternalFunctions.ttcn
 
/*  external */ function fx_NasIntegrityAlgorithm(octetstring   p_EncodedNasPdu,
                                             B3_Type       p_IntegrityAlgorithm,
                                             B128_Key_Type p_KNASint,
                                             NasCount_Type p_NasCount,
                                             B5_Type       p_BearerId,    /* @sic R5-101050: BearerId changed to 5 bits sic@ */
                                             MAC_Direction_Type p_Direction) return MessageAuthenticationCode 
{
return 'FF00FF00'O
};    /* @status    APPROVED (LTE) */

  /*external*/ function fx_NasCiphering(octetstring p_EncodedNasPdu,
                                    B3_Type       p_CipheringAlgorithm,
                                    B128_Key_Type p_KNASenc,
                                    NasCount_Type p_NasCount,
                                    B5_Type p_BearerId) return octetstring {  return ''O } ;                                       /* @sic R5-101050: BearerId changed to 5 bits sic@
                                                                                                                     @status    APPROVED (LTE) */

  /*external*/ function fx_NasDeciphering(octetstring p_CipheredNasMsg,
                                      B3_Type       p_CipheringAlgorithm,
                                      B128_Key_Type p_KNASenc,
                                      NasCount_Type p_NasCount,
                                      B5_Type p_BearerId) return octetstring  {  return ''O } ;                                     /*  @sic R5-101050: BearerId changed to 5 bits sic@
                                                                                                   




With this , the UTRAN suite will compile.





One may notice that lot less modifications are needed here that were for the ETSI suites. The reason is that 3gpp uses Titan, in parallel with other commercial
tools to validate their test suites during development.



Best regards
Elemer




[Updated on: Thu, 24 May 2018 16:13]

Report message to a moderator

Previous Topic:How to initialize OCTETSTRING from char* in an external function?
Next Topic:State of the Osmocom TTCN-3 Test Suites
Goto Forum:
  


Current Time: Tue Sep 25 17:40:38 GMT 2018

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

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

Back to the top