• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

LTE Development - Pressing the accelerator for LTE

Operators need to be able to ensure LTE terminals can meet their own network  requirements, but in the most efficient manner possible. Can flow charts really help?

Although LTE terminals need to pass tests prescribed by GCF (Global Certification Forum) and PTCRB (PCS Type Certification Review Board), there is a growing requirement to simulate scenarios required by Network Operators to prove their own "real world" requirements.

TTCN is mandated for the conformance tests by ETSI. However, for laboratory simulation of network scenarios, there are a growing number of terminal developers that are looking for more flexible tools to develop and prove their products. While TTCN and C-based languages dominate the majority of 2G / 3G development, some graphical interpretations of these low level languages have attempted to simplify programming. They still require the programmer to have a detailed knowledge of the 3GPP protocols and still use a script based language.

Anritsu took a bold step when it introduced a unique "graphical flow chart" tool (The RTD - Rapid Test Designer) for GERAN and UTRAN scenario development. This became popular with Network Operators for acceptance testing of terminals as it provided an easily understood method to simulate the behaviour of terminals more closely replicating the requirements of the network as opposed to just meeting 3GPP specifications. With LTE there are signs that "graphical flow chart" tools may be used by many developers to accelerate their developments and especially to make the maintenance and iteration of the tests easier.

TTCN FOR AND AGAINST
TTCN was chosen as a scripting language by ETSI for use in conformance testing and is now internationally used for modern communication systems. TTCN allows separation of the Abstract Test Suites and the Adapter Layer which allows portability of the tests to make them platform independent. However this does mean that individual adapters need to be maintained to translate the tests to work with every different platform. This requires significant effort (in developing and checking) to ensure that the UE configuration provided through RRC signalling matches exactly with the SS configuration.

TTCN-3
TTCN-3 has been developed by ETSI as a successor to TTCN-2. Despite sharing the same fundamental concepts, TTCN-2 and TTCN-3 are essentially two different languages - even the TTCN acronym has changed from "Tree and Tabular Combined Notation" to "Test and Test Control Notation". TTCN-3 has a look and feel of Java/C++ which should discourage the resistance from some developers. It also provides a more graphical look which will improve and enhance its usability.

PROCEDURAL BLOCKS - THE HEART OF ANY PROTOCOL DEVELOPMENT TOOL
The concept of using a graphical tool is not unique in other areas of development: using building blocks that are added to a blank canvas to produce a logical test progression with branching and looping has been available commercially for many years. Visually showing the path of different outcomes to a scenario benefits not only the originator but also engineers that may want to further develop the test. The Anritsu RTD uses procedural blocks, derived from the ASN.1 that is created for every 3GPP release and maintained along with any further 3GPP specification releases. As well as providing a test that is visually appealing, it allows test variants to be easily created and tests to be updated automatically, saving considerable time and possible errors.

KISS - KEEP IT SIMPLE, STUPID
By simplifying any complex problem there is a danger that flexibility and detail is sacrificed. The trick is to hide the complexity from those that do not need it and allow the more experienced to be able to "drill down" into the details. The RTD procedures can be opened up to show the IE (information elements) within them and then edited using drop down menus or entering data in fields that are then checked. This makes test variants straightforward to create so once a complex test is created and proven; test coverage may be expanded by using less skilled programmers.

A number of standard RABs (radio bearers) are provided within the RTD which satisfy the majority of users. Radio bearers can be created by the user to generate specific conditions that may be needed to replicate live Networks. This can be done manually or by Log Import Tools that allow transfer of information gathered in the field to create catalogs and network models for use with existing test cases.

SOME THINGS NEVER CHANGE - OR DO THEY?
There are some scenarios that may rarely change: for example a registration process. Once a process has been developed to allow all types of registration to be covered, it may be used in virtually every subsequent test. Traditionally a call to a subroutine would have been used with a large amount of associated code. With graphical test flow the process can be turned into a single procedural block (or compound) and simply placed in each test. The compound appears in the picker area for future users.

Inevitably the process will need to be changed to meet a new specification change or to add a feature and this would normally require the iteration of every test using the subroutine. Using TTCN would require significant effort to evaluate the necessary parameterization of a TTCN object (test step/constraint), in order to provide a good trade-off between flexibility of TTCN object re-use and complexity. If this is not properly done (which is generally the case), the number of 'duplicated' TTCN objects will grow linearly (if not exponentially) with your test cases. This creates test suite maintenance nightmares.

The RTD provides an option to allow the compound procedure to be changed once and replicated across all the tests that use it automatically.

NETWORK MODELS AND CATALOGS
Any laboratory network simulator will be constrained by the number of cells that can be simulated. In general scenarios need up to three for serving cells, neighbour cell and a cell to handover to. In order to make configuration and control of the simulator easier, network models can be created that allow the cells to be populated with specific parameters and save complex programming of parameter in each step of the test.

FUTURE FOR GRAPHICAL FLOW
The RTD has now evolved to include LTE and it is being used in terminal design to simplify and accelerate development with a LTE lower layer procedure library as well as LTE Layer 3 procedures. Although Layer 3 procedures are well suited to integration of terminals and overall behaviour, lower layer procedures are needed for development of the terminals. RTD now provides procedure libraries for Layer 3 LTE and Lower layer LTE procedure libraries. Engineers can now create their own scenarios for the development of lower layers and then create their own compound procedures that can be used in L3 tests for further development and integration of devices.

The RTD's graphical flow can show real-time test progress and can be used to debug terminals using functions defined by the user. 

TEST OUTCOMES AND RESULTS
The RTD produces a comprehensive set of results and because these Logs contain, the Message sequences between the network simulator and the terminal as well as a copy of the test in a self contained environment, debugging is much simpler. For other RTD users the results can be examined in detail with full linking and expansion of all messages. They may also be exported to HTML after any pre-filtering of detail, where anyone with a web browser can view the messages.

RTD provides a collection of unique tools to speed up development and integration of modern wireless terminals. It also provides a common path to network operators' requirements and will be the way to get LTE terminals into the market in time.

Источник: Mobile Europe

Оставить свой комментарий:

Комментарии по материалу