Rapport

{EPITECH.
} European Institute of Technology
INTERNSHIP REPORT
2007.03.19 2007.12.31
TNG Technology Consulting Software Consulting
Laurent Malvert malver_l laurent.malvert@epitech.net
Abstract This document introduces the different tasks of the final internship assignment performed between March and August 2007 by the author as a software consultant contracted by TNG Technology Consulting GmbH in order to validate the {EPITECH.} Expert degree.
Internship Report TNG Technology Consulting
{European Institute of Technology.} II
TABLE OF CONTENTS
ACKNOWLEDGMENTS
SUMMARY 1. 2. 3. TNG TECHNOLOGY CONSULTING MISSION STATEMENT INTERNSHIP COMPLETION STAGES
7 7 7 8
THE ENTERPRISE: BRANCHES, ACTIVITIES & CUSTOMERS 1. 2. 3. 4. 5. THE LINE OF BUSINESS: IT CONSULTING THE ENTERPRISE: TNG TECHNOLOGY CONSULTING INDUSTRY SECTORS AND TNG CUSTOMERS DEPARTMENTS AND SERVICES THE POSITION: WORKING AS A TNG SOFTWARE CONSULTANT
9 9 9 12 13 13
ASSIGNMENTS 1. 1.1. 1.2. 1.3. 2. 2.1. 2.2. 2.3. 3. TNG: BUSINESS INTELLIGENCE AND TECHNOLOGY WATCH GOOGLE SERVICES WIRECARD MISCELLANEOUS: PROJECTS PROPOSALS, TECHNICAL TALKS AND OTHER TASKS O2: SOFTWARE DEVELOPMENT AND TESTING NOKIA CDR-TOOLS DSL-SIMULATOR FONIC PROJECT TESTING OVERALL TIMELINE
15 15 15 18 20 22 22 28 30 37
CONCLUSION
39
BIBLIOGRAPHY GLOSSARY APPENDIXES
41 43 45
{European Institute of Technology.} III
{European Institute of Technology.} IV
ACKNOWLEDGMENTS
The author wishes to express sincere appreciation and thanks to all his coworkers at TNG Technology Consulting for their assistance during this internship and for their technically challenging and instructive entourage.
In addition, the author would like to thank his customer contacts by O2 Germany GmbH for their proposed projects and their allowance to publish this material.
Special thanks are addressed to the following persons for their collaboration with and/or involvement in the projects presented throughout this report (alphabetically):
At TNG: o K. Behrmann o J. Benilov o R. Dalhke o M. Frtsch o H. Klagges o W. Koska o J. Meltzer o G. Mller o S. Nagy o G. Pache o R. Pintarelli o E. Reinel o M. Schikowski. o S. Stamminger o C. Stock o H. Wilhelmi o G. Winkler At O2 Service: o R. Steinbacher o D. Wagner
{European Institute of Technology.} V
{European Institute of Technology.} VI
Summary
This report presents exhaustively the work that has been realized at TNG Technology Consulting between the 19th of March and the 31st of December 2007 during the last internship completing the 5th year of study and the whole curriculum at the European Institute of Technology. The company the internship has been done in, as well as the projects that were worked on, have all been chosen in respect of their technically and humanly challenging specifications, requirements and conditions. Those are fully explained and detailed later on through this document, as are the obtained results and learned lessons.
1. TNG Technology Consulting

TNG Technology Consulting GmbH (TNG) is a German company based in Unterfhring, in the state of Bayern. Founded in 2001, and currently composed of 36 technically highly-skilled co-workers, TNG poses as a cutting-edge and innovative software consulting partnership, which mission is to address strategic or critical IT concerns. The whereabouts, organization and internal workings of TNG as well as the working environment constituted by TNG itself and its net of customers and partners will later be exposed in this documents Enterprise chapter.
2. Mission Statement
This internship, because of the very nature of a consulting company and of the software consultant position, does not come with any fixed initially assigned mission statements or objectives. Indeed, the role of a TNG software consultant is to analyze and solve specific IT related issues for various customers, each of them evolving in numerous domains that compose the broad range of industry branches they deal with. This makes the global work environment of a given project potentially very different from another one, whether it is considered from a technical, geographical or human point of view. TNGs areas of expertise and activity are relatively wide. Therefore, the consultant is required to be able to professionally provide the customer with his technical and managerial proficiency as he might be meant to act as a multi-task effective actor, namely: a programmer a developer a tester an adviser a team-leader a project-manager
{European Institute of Technology.} 7
Internship Report TNG Technology Consulting Depending on the project the consultant works either on site in the customers offices or remotely from TNGs offices, and should always abide to TNGs Code of Ethics. As of this writing, various kinds of projects have been accomplished throughout this internship, with different mission-specific roles and objectives, covering various topics and technologies. All of which will all be further detailed in the Assignments chapter of this document.
3. Internship Completion Stages

As explained earlier, because of the nature of software consultancy, this internship involved different projects and inherent tasks. Hence, this document and particularly its Assignments chapter, will exhaustively list the tasks that the author was required to accomplish. However, it will focus more extensively on the main projects, as those allow to clearly distinct noticeable stages throughout the internship. Except for the expectable maintenance operations and other minor technology watch-related tasks that are bound to any software development project and are not listed here, it unwound according to the following structure, which is the one this documents presentation will be based on : TNG internal projects: o (Technology Watch) Google Services o (Business Intelligence) Wirecard O2 remote projects: o (Development) Nokia CDR-Tools o (Development) DSL-Simulator O2 on-site projects: o (Development & Testing) Fonic Platform
The Enterprise: Branches, Activities & Customers

1. The Line of Business: IT Consulting
Information Technologies encompass all forms of technology used to create, store, exchange, and use information in its various forms while consulting is an activity where professionals provide expert advice in a particular domain or area of expertise to demanding customers. With the dawn of the computer age and the explosion of the internet bubble, consultancy has become one of the leading and most active markets when it comes to the edition of software products, whether they are meant for internal and / or commercial purposes. However, software consulting does not just limit itself to the development and production of software, but also to the trading of expert skills related to all the surrounding technologies and capabilities present in the IT field: hardware, networking, management, business intelligence and risk assessment, to name a few. The role of an IT consulting company merely is to provide solutions to technical and non-technical problems that may occur down the pipe of technology embarking goods production. It is also to provide theoretical advice and hands-on aid to businesses on how to make the best use of Information Technologies to meet their objectives.
2. The Enterprise: TNG Technology Consulting
2.1. History
TNG Technology Consulting GmbH is a software consulting company based in Unterfhring (Bayern, Germany), that was founded in 2001. It is to notice that TNGs amount of co-workers as well as its range of customers has expanded rapidly over the last years and still increases, and that the company never had to resort to any financial aid or bank credit. This testifies of its overall management and production quality, making it a successful post-2000 emerging company.
2.2. Organization
TNG is a partnership founded by the following six partners:
Christoph Stock
Eike Reinel
Gerhard Mller
Harald Wilhelmi
Henrik Klagges
Oliver Soos
Figure 1 - Partners
Every year, a new board of 3 directors is elected by the aforementioned partners to lead the company during the upcoming year:
Board of Directors 2006 2007
H. Klagges
G. Mller
E. Reinel
H. Klagges
G. Mller
C. Stock
Figure 2 - Board of Directors
Most of the decision taking-processes by TNG are based on the 4-eyes principle, which implies that at least 2 of the current directors should always approve any corporate action. A decision met by the board can be later overruled by a mutual decision of the partners.
Partners Directors Consultants Interns

Figure 3 - Decision-taking precedence
At the date of this writing, TNG employs: 36 staff managers and consultants 3 interns.
2.3. Philosophy
Working at TNG requires, in contrast with a herd of companies which believe in a stronger and deeper managerial structure; a great deal of involvement, and a high level of interaction between all
Internship Report TNG Technology Consulting the co-workers, which makes it possible for all the experts to evolve personally as well as professionally in the company. This philosophy and the 4 eyes principles are also reflected in the project management schemes, where decisions are to be validated by consensus. In addition to this, all TNG software consultants are meant to act as professionals and experts when they are on duty and should implicitly abide by the TNGs Code of Ethics.
2.4. Code of Ethics

TNGs Code of Ethics (CoE) defines the different obligations that are to be met by any TNG employee in all case. The CoE, based on the IMC USAs Code separates 3 different fields of action, which are explained below but are not fully detailed for the sake of clarity, brevity and conciseness.
Our Obligations towards the Consultant-to-Customer Relationship

Values: Integrity, Competency, Independency, Objectivity, Professionalism Realistic duty-related expectations Essential Knowledge and Proficiency Understanding of the Goals, the Perimeter and the Operation Chart Addressing a customers confidential matters accordingly Matters and Conflicts of Interest Pulling-back when Objectivity or Integrity have been impaired Head-hunting on consultation only
Our Obligations towards the Financial Integrity

Remuneration basis forefront agreement No personal gain Divulgation of financial interests
Our Obligations towards the Openness and Reputation

Reporting harmful or illegal activities Respecting the rights of consulting colleagues and firms Integrity and Professionalism No misleading publicity and no decrying of the competition Abidance to the Code
3. Industry Sectors and TNG customers

The typical TNG customers are large or multinational concerns. Here is a list of TNGs example clients for each active industry sector. (Company names are not listed for confidentiality reasons) an international premium car manufacturer a car IT components supplier
Automotive
Aerospace & Defense Banking & Finance eCommerce Education Electronics Information Technologies
a system and software house an online payment provider a German bank a German online broker a manufacturing and machinery marketplace an online virtual goods marketplace
a US student community an international linguistic services company
a multinational EE company
a UNIX server hardware manufacturer a specialized IT services provider
Insurance
Logistics & Franchising Media & Publishing Telecommunications
an international insurance company
international franchise in the food sector a warehouse goods tracking specialist a German daily-newspaper publishing house a public radio station a mobile telecommunications operator a mobile hardware and software supplier
Figure 4 - Customers
4. Departments and Services

TNG Technology Consulting provides services in 3 main areas of expertise, where employees pose both as implementers and consultants (for a complete and detailed listing of the offered services and capabilities, please report to the Appendix A: Enterprise Documentation) I M P LEM ENT ATI ON Design and Implementation Testing , Tuning, Maintainance Focus on : o Enterprise Java Software o C# Development o C/C++ o Python o Perl o Network and Services Monitoring Operation Data Evaluation Clusters & High Availability Services Administration Scripting & Server / SAN Administration Operations C O N SULT I N G Code Review Architecture Best Practices Software Refactoring Software Verification
IT Management
Project Management Project Office Analysis

Table 5 - Services
Security o Audits o Cryptography o PKI Provider and Outsourcer Control Network Design Data-Centers Setup and Migration Troubleshooting IT-based Business Strategies Consulting and Research Studies
5. The Position: Working as a TNG Software Consultant

The skills that were used as prerequisites at the time of the hiring were principally technical skills regarding programming languages and software engineering techniques. This internship therefore was more actively focused on activities related to the Software Development services (see Table 5). It was spent by working 6 months as an employed TNG Software Consultant, posing at first as an internal developer and analyst in charge of minor technology watch and business intelligence matters, to be later assigned to work on external projects, developed either individually or in teams, at TNGs or the customers offices. Those projects goals, specifications and results are detailed in the upcoming Assignments chapter.
Assignments
Note: the following projects specifications, samples and excerpts have either been: voluntarily obfuscated to preserve sensitive datas confidentiality voluntarily stripped to preserve sensitive workflows confidentiality
1. TNG: Business Intelligence and Technology Watch

During the first month of the internship, while it was necessary to wait for a contract opportunity or a fix position to open and to wait for projects proposals to be validated, most of the tasks were focused on internal business intelligence analysis and technology watch matters.
1.1. Google Services

The purpose of this project was to evaluate, based on a customers request, the feasibility of a Google AdSense and Google Maps based online or mobile embedded route planner targeting the mountain bike and city bike markets.
1.1.1. Requirements 1.1.1.1. Objectives

Still in its very early conception stage, this project didnt come up with precise specifications. The primary objective would have been to build an online portal accessible through the internet or from an embedded device to build a custom route planner. The particularity of this route planner was that it would have required the ability to determine accurate paths and waypoints for biking routes, whereas those tools are nowadays mostly targeted at the automotive market. The secondary objective would have been to have the possibility of viewing contextsensitive advertisements or information about local concerns.
Figure 6 - Route Planning Demo with Google Maps API
Internship Report TNG Technology Consulting For instance, for a specific route: Bike-shops or maintenance offices Points of Views and Points and Interest Biking-clubs
1.1.1.2. Specifications
Because of the nature of project and the limited amount of resources (namely time and manpower) that could have been dedicated to this project, it was deemed necessary to focus on technologies that would allow the implementation of a minimalist solution with a minimum of effort in a minimum of time, hence the need to consider existing frameworks ready to be used out-of-the-box. Therefore we chose to evaluate the project viability from a feasibility point of view with the most straight-forward scenario, which implied the following study points:
Route Planning
Performing path-finding operations with Google Maps Defining specific routes with Google Maps Defining routes than are not part of standard road-networks Study alternative products that could serve similar purposes
Context-sensitive Information network
Displaying context-based adverts from on geo-coded information Displaying context-based adverts from textual-content or queries Feasibility of an integrated Google AdSense solution
1.1.2. Development Report 1.1.2.1. Realization
The realization of this project was broken down in different tasks: Performing feasibility tests using the Google Maps API Performing feasibility tests using the Google AdSense API Researching and comparing other existing APIs
Fulfilling the study implied of course the development of several tests and demos to verify the aforementioned points validity and evaluate the complexity of the project in regard of the resources constraints. It also required interacting with the Google Maps and Google AdSenses teams for further investigation of the APIs modularity and future evolutions.
1.1.2.2. Results
The results could be summed up with the following matrix: A DV AN T AGES Route definition support Path-finding support Geo-positioning support Pinpoints support Acceptable latency Ease of integration Quality of the text-sensitive ads Possibility to ban competitors D R AW BACKS Non-permissive license Requires web access
Google Maps API
Google AdSense API
Solutions plethora Alternative Mapping Possible workarounds APIs Open-Source frameworks

Table 7 - Google APIs' Comparative Results
Restricted graphical charter No really fine-grained control Requires web access No programmatic API Painful integration Unreliable support Indirectly expensive
As it can be noticed here, the Google Maps API revealed itself to be a very interesting solution from a technical point of view, except for its non-permissive license, which forbids the use of the path-finding algorithms or web-services for automated / programmed route calculation. This drawback is unfortunately more important than meets the eye at first, because it would have implied the reimplementation of the restricted routines or the integration with another path-finding framework to interact with the Google Maps. Another problem is the use of the Google Maps API only through the online web-services, which forbids a non-networked mobile device to be able to use the final product, thus forbidding bikers to rethink their route while they are on their way. Regarding the Google AdSense API, this appeared to be the biggest problem. While it would have been possible to work around the Google Maps API with alternative solutions, the Google AdSenses features would have been the best bet for a fast implementation meeting with the stress deadline. However, its license forbids modifying the appearance of the advertising snippets, and it is not really possible to control the adverts selection to obtain fine-grained selection. Finally, the Google AdSense API did not meet up with TNGs expectations as it is only meant to control a farm of Google AdSense accounts (like on a blogging platform which would give its users the possibility to use AdSense, for instance), and cannot be used to programmatically control the advertising routines. Considering all those non-expected results, the project would have deviated from the foreseen scenario and did not appear to be viable as it would have required more time and human-resources than initially expected. Therefore, this project proposal was rejected.
1.2. Wirecard
Wirecard AG is one of the strongest TNG clients, where a handful of consultants work full-time on several projects. During March 2007, TNG wanted to assert the popularity and market penetration of the latest Wirecard AGs line of products: the Wirecard online credit-cards. It was also requested to study how the new Wirecards release had impacted the overall financial stability of the Wirecard AG company.

Research and document the Wirecards online popularity among the average online customers, as well as Wirecard AGs financial status.
It was request for this research / analysis project to report on Wirecard AGs and the Wirecards following points: General on-line exposure Financial status / health Customer satisfaction Overall corporate image
This report was to be researched, written and delivered over a 2-days period and to be filed in with appropriate support documentation.

This quite short-lived project did not rest upon technical skills and knowledge, and consisted in the drafting of a summarized business intelligence report for G. Mller, one of the TNG partners and software consultants working at Wirecard. To understand which information had to be filtered, it was important to determine the following key points (ordered by priority): Online banking analysis o Key sectors and indicators Overall health Growth potential o Active concerns Wirecard AG o Organization o Known facts o Financial health o Reputation o Business plan Wirecard CC analysis o Customers {European Institute of Technology.} 18
Internship Report TNG Technology Consulting Listing Satisfaction poll o Competitors Listing Comparison of Wirecard CC and its rivals o Exposure Events Press Web
1.2.2.2. Results
Below is a screenshot of the mind-map which was filed in with the report (critical and sensitive nodes have been stripped or folded for confidentiality reasons).
Figure 8 - Wirecard Analysis MindMap
1.3. Miscellaneous: Projects Proposals, Technical Talks and other Tasks

Among all other projects realized by TNG, there are also a lot of smaller routine day-to-day consulting tasks, particularly focused on the research of new projects and clients, as well as the permanent education of all TNG consultants.
1.1.1. Project Studies and Draft Proposals

Researching new projects and clients, evaluating a customers request or drafting a proposal for a future project that might be realized by TNG is a chronic activity, often carried out by the senior TNG staff or partners. However, on some particular occasions, it can happen that other consultants might be required to give a helping hand in order to get a wider range of opinions. Besides, the Information Technologies covering a huge field of miscellaneous expertise, it is not conceivable to expect every consultant to have an exhaustive and absolute wisdom in all things. It is therefore commonplace to request other colleagues for comments when it is supposed that one of them among the group might be able to provide a more proficient criticism.
1.1.2. Talks: TechDays and OfficeDays

As it has been stated earlier, IT is a very broad field, evolving at a very fast pace. Therefore it is TNGs belief that consultants should not only professionally but also personally carry out research about the latest technological improvements and discoveries and to share this knowledge with the group to help everyone to integrate the flow of information. Likewise, TNG will support employees willing to participate in IT-related events, for instance: User Groups meetings (Java User Group, Microsoft User Group, ) Conferences and Workshops (Google Developer Day, )
To capitalize on this cutting-edge knowledge and help to widespread it among its consultants, TNG organizes twice a month all teams-meetings at the office. Those meetings are called the TechDays and OfficeDays. The goal of TechDays and OfficeDays is namely to give the consultants a chance to meet up and talk about their latest experiences. It might be an appropriate time to: report about specific problems with an ongoing project by a customer exchange information about the latest buzzing-technology request help from colleagues in a particular field of expertise
Occasionally, TNG will also invite external speakers, usually involved in an emerging Open Source software project, or even specialists in IT-related fields, whether they are professional developers, enthusiasts, authors or researchers.
Internship Report TNG Technology Consulting This is also the occasion for the TNG management staff to perform a quick rundown so that everybody in the company will be up-to-speed and aware of the latest corporate news. In addition to this, the casual and informal ambiance makes it easier on TechDays / OfficeDays for new coworkers to become integrated and get familiar with the whole team, introduce themselves and their background. For instance, it was a good occasion to meet up with the team and share knowledge about the current economical and educational status of IT in China.
Figure 9 - TechDay Talk about the IT in China
Also, it allowed the author to perform another presentation on the whole panel of Google online services, as the knowledge acquired with the project exposed in 1.1 Google Services offered a good opportunity to research uncommon or even unknown features and to bring the spotlight on them.
Figure 10 - TechDay Talk about Google Services
2. O2: Software Development and Testing

The rest of the internship was spent working mostly on projects for different services of O2 Germany. For the sake of clarity and brevity, this section will focus on the presentation of the three most relevant projects, all of which consisting in software development and consulting services.
2.1. Nokia CDR-Tools

The Nokia CDR-Tools is a project developed for O2 Germany. It represents both a set of scripts and a programmatic framework to be reused internally by O2, in order to analyze and produce Call Data Records, sometimes also know as Call Detail Records or Customer Data Records (CDRs). Those CDRs are most generally generated by PBX and PMS systems during or at the end of a phone call. They then contain information, sometimes in clear or compressed form, such as: the duration of the call the caller the callee the type of the call (WAP, Internet, GPRS, SMS, MMS, Voice ) the origin and destination types of the call (national / international) transported data (in the case of SMS attachments for instance)
For more information regarding CDRs, please refer to the appendixes.

The Nokia CDR-Tools can be viewed as a 2-steps development project.
The Nokia CDR Framework

CDR manipulation capabilities: generation support compression and decompression support error-reporting support platform, performance and maintainance prerequisites: extensibility and modularity (for future versions of the CDR specifications) portability (target platform: HP-UX) efficiency (CDRs sets can be really large and come in very high quantity) simplicity
The Nokia CDR Tool Chain

binary-to-text conversion tool binary-compressed form to human-readable form conversion automatic addition of extensive comments text-to-binary conversion tool human-readable form to binary-compressed form conversion automatic normalization of the CDR set to comply with the CDR specifications filtering / search tool fast and automatic filtering of specific CDRs in a given binary-compressed set automatic normalization to generate conglomerate CDRs editing tool in-place edition of binary-compressed CDRs
The project proposal came bundled with drafted specifications for the CDR format in use on production systems and with more detailed specifications for the demanded behavior of the CDR-Tools. CDR S P ECIF ICAT ION S While unfortunately the CDR formats specifications cannot be exposed in this document for confidentiality reasons and because they are too verbose to be detailed here, they can be simplified with the following schema:
SETS BLOCKS
multiple blocks infinite size multiple CDRs various fixed sizes (8K, 32K, 64K, ...) CDRs are padded to fill the space record identification code record length fields containing call information
RECORDS
FIELDS
Figure 11 - CDR Encapsulation
call information various datatypes various compression schemes various length
As it can be noticed with the above schematization of the CDR-format, it is a simple encapsulated transport layer, allowing for on-the-fly fast input/output of fixed-size records. Each CDR contains various piece of information, each one described as a field being precisely defined in the CDR specifications provided by O2. CDRs are then grouped in fixedsized blocks using the following structure:
Header Record
Special CDR indicating a block's front Provides valuable information about the current block 0 to N records fitting in the current block's size Each CDR contains phone-calls' relative information
Standard Record(s)
Trailer Record
Special CDR indicating a block's back Provides valuable information about the current block
optional (only in binary-compressed form) padds the current block to fill unused space
Figure 12 CDR Block Structure
Block Padding
Internship Report TNG Technology Consulting T OOL C HAIN

Environment Progamming Language: Perl 5.8 Platform: HP-UX 11.11 Standalone software (no dependencies) Non-intrusive software (for non-privileged user) Functional Requirements - Tools
AN D
F RAMEWORK S P ECIF ICAT ION S
Tool chain binary-to-text converter nokia_dump text-to-binary converter nokia_undump binary-filter nokia_grep binary-editor nokia_edit Extended human-readable format each record has a short informative header each field is displayed as follows: <field name>: <value> # <human readable interpretation> Filtering abilities by record identification code by record type by field value Error handling informative error messages nokia_edit support for "goto-faulty-line" editing Pipe support Online documentation
Functional Requirements - Basic API Sketch Generator::add_cdr() Generator::to_file() Generator::outfile_ascii() Generator::outfile_binary() Generator::infile_ascii() Generator::infile_binary() Generator::flush() Generator::clear() Generator::read_cdr() Generator::write_cdr() Generator::get_cdrs() Generator::close() Non-Functional Requirements large file support ease of maintainance
Figure 13 - CDR-Tools Specifications

This project was developed over a cumulated period of two months, including: project draft conception development customer delivery technical support
C ON CEP T ION The Nokia CDR-Tools project was originally meant to be built by reflecting the capabilities of a now obsolete tool performing similar CDR manipulation operations with GSM CDRs. However, after a short period of time, it became clear that it would be simpler to only reproduce the same overall structure as the previous framework but to re-implement its internal mechanisms completely, to improve its modularity and to meet up with the custom ers performance requirements. The Nokia CDR-Tools use pre-CDR-processing capabilities and integrated precognition features to generate at runtime pools of pre-calculated data, allowing the CDR-Tools to handle a very large amount of very large files with a challenging processing pace.
Pre-Computations
CDR analysis
identification parsing construction and collection
Perl Runtime startup Framework loading
array / hash conversions flyweightstructure
file loading block scanning
Tool Startup
Sequential CDR Set Loading
block checking CDR output block padding error reporting
Sequential CDR Set Writing
Figure 14 - Standard CDR-tool Workflow
In order to achieve the desired level of adaptability and to implement the above computational workflow, the projects architecture was separated into modular entities using Perl Object-Oriented programming techniques.
/
Nokia CDR-Tools
cdrdata/
CDR samples
bin/
tool chain
doc/
documentation
lib/
framework
tests/
unit-tests
api/ nokia_dump developer documentation
Error/ errors & failsafes
nokia_edit
examples/
Nokia/
use-case examples
CDR support
nokia_grep
guides/ complete guides
IO/ streams / Files
man/ nokia_undump user documentation specs/ technical specifications

Figure 15 - Nokia CDR Tools Project Architecture
Util/ convenience tools
D EVEL OP MEN T It was developed remotely from TNGs office as it was a one-man contract which did not require the consultant to work on-site or the setup of any prerequisite development architecture. The product was incrementally developed, punctuated by regular e-mails and telephone checks with the O2 managing developers and the customer contact. It is only developed with core packages and modules of the standard Perl distribution for portability reasons and to meet O2s requirements for a standalone and non-intrusive commandline / console-based software. D EL IVERY AN D T ECHN ICAL S UP P ORT The product was delivered upon validation by O2 and presented to the succeeding team in charge of any future development. Technical support is currently still ongoing to implement minor changes to meet dynamic customer requirements.
2.1.2.2. Results
As of today, the Nokia CDR-Tools are still in use by O2 and other CDR manipulation tools are being developed by another TNG team upon its programmatic interface. The following graphics present the respective layout of text and binary-compressed CDRs produced with the Nokia CDR-Tools, with a comparative presentation of their different subparts. Figure 16 - Raw Binary CDR
Figure 17 - Formatted Binary CDR
It is possible to clearly see the padding characters following the trailer record both in Figure 16 and Figure 17. It is possible to extract identical field values from Figure 18 and find their matching entries in Figure 17.
Figure 18 - Text CDR
2.2. DSL-Simulator
The DSL-Simulator is a project developed for O2 Germany. It is an O2 internal piece of software, formerly developed by TNG and a third-party company called Danet. The main goal of the DSLSimulator is to provide an automated test-suite used by O2 to assess the robustness and completeness of Telefonicas and O2s DSL solutions. This project started later than expected because of extended contract-negotiation delays, allowing the team to jump-start its development just after the end of the Nokia CDR-Tools project.

The DSL-Simulator projects objectives consist in a normalization of the simulators behaviours, so that it will be able to reproduce test-cases for the upcoming version of Telefonica/O2 DSL solutions. This normalization requirement was defined by a set of single features to be implemented in the simulators existing code-base, already developed in 2006 by TNG consultant M. Schikowski for the previous Telefonica/O2-DSL systems version.
The DSL-Simulator acts as an intermediary agent in client-server architecture. It is composed of 2 different parts: The DSL-Simulator software itself, which is a combination of o an HTTP server to receive incoming requests o an HTTP client to emit synchronous and / or asynchronous responses o a processing kernel to determine the responses to be triggered based on the incoming requests type an emitter script, used to fire specific messages at the DSL-Simulator over HTTP
The DSL-Simulator uses HTML-encapsulated XML messages to communicate with its counterparts. That is, any kind of XML message that is sent over HTTP. HTTP is here only used as a transport layer (refer to the appendixes for a request sample). Upon reception of an incoming request fired by the emitter, the simulator will respect the procedure explained in the following schema:
Triggered Responses Standard Request Incoming Request Request Processor Command Handler Forced Responses
Standard Request
Synchronous Acknownledgment Response Workflow Manager
Triggered Responses
Figure 19 - DSL-Simulator Request Processing
The Simulator can receive two different types of incoming requests, identified as seen on Figure 16 by the request processor: the so-called Standard Requests Those are the most common types of incoming requests. Defined by O2, they contain customer information and are expected to trigger various possible asynchronous workflows, which can also depend on runtime conditions, as well as a synchronous acknowledgment response. the so-called Simulator Commands Those requests are convenience commands that can be sent to the DSL-Simulator using the same transmission channel, allowing it to perform any kind of custom action: o firing messages o pausing/resuming responses o cancelling ongoing workflows o resetting simulators kernel status o restarting the simulator (kernel + server)

This project was developed over a cumulated period of 1.5 months by a team of 3 TNG developers. (see the timeline) The DSL-Simulator is Java-based software, and uses only Java 5 features to facilitate portability by limiting external dependencies, except for: the Quartz Scheduler Used to implement multi-threaded request management capabilities to support heavy-load performance tests of O2 DSLs interfaces the Apache Log4J / Appache Commons Logging library Used to implement logging capabilities and ease the storage of processed requests the JUnit and XMLUnit testing-suites Used to implement unit-tests based on the XML input/output messages
2.2.2.2. Results
The DSL-Simulator software is currently being used by O2 to perform robustness and performance tests on his DSL solutions in contemplation of its upcoming version upgrade.
2.3. Fonic Project Testing

Fonic is a project developed by O2-Service Germany GmbH, scheduled to be release in September 2007. It is an O2 Mobile customer service developed by joint development force from O2, O2-Service, TNG and a third-party company: CDRator. Started in 2006, the Fonic project entered his final testing phase in May 2007 when a TNG coworker (J. Benilov) was recruited by O2-Service to lead a small team of software testers and report bugs to: the CDRator developers in charge of the data processing and customer care software the O2 / TNG developers in charge of the CDR/SDR interfaces
The test-team was extended during the second half of July; at the time the DSL-Simulator project was reaching completion and prepared to be delivered.

The initial project objectives were the automation of testing processes for the Fonic SDR Interface. That is, the part of the whole Fonic system supposed to produce the Service Data Records when any kind of phone call takes place on the O2 mobile network. However, because of human-resources restructuration down the way to the final deadline, the testing-team was reorganized and new objectives assigned, namely to also test the SDR Interface and its integration in the whole system. It was also requested toward the end of the contract to come up with a custom backup solution for the test-teams documentation resources (Wiki, SubVersioN, JIRA Bugtracker ).
SDR S P ECIF ICAT ION S The SDR Interface specifications match rather closely the ones of the CDR Interface presented earlier in this document (the Service Data Records are actually formed from data extracted from Call Data Records and from Customer Care support databases. Whilst the CDR Interface used binary compressed data, the SDR Interface uses clear-text data only filled with only one block per file and one record per line. Thus, there is no block padding sequences, but we still have field padding sequences. Also, there are only three different kinds of records (Headers, Trailers, and Standard Records) whereas the CDR Interface had a much higher number of possible records. Like the CDR Interface specifications, it is unfortunately problematic to expose the SDR specifications, because of their complexity and confidentiality. However, the overall structure can be described:
SETS / BLOCK
1 set = 1 block = 1 file infinite size infinite number of SDRs only 3 SDR types fixed length records (224bytes) fields containing service data service information various datatypes fixed length
RECORDS
FIELDS
Figure 20 - SDR Encapsulation
SDRs are being sent over to O2-Service as GZip compressed files over a FTP connection, with each uncompressed file using the following structure:
Header Record
Special SDR indicating a block's front Provides valuable information about the current block 0 to N records fitting in the current block's size Each SDR contains phone-calls' relative information Special SDR indicating a block's back Provides valuable information about the current block
Standard Record(s)
Trailer Record
Figure 21 - SDR Block/File Structure
Internship Report TNG Technology Consulting T EST S S P ECIF ICAT ION S Performance Tests SDR-Loader Engine performance SDR-Rating Engine performance Efficiency stress-testing Documentation Robustness Tests SDR-Loader Engine robustness SDR-Rating Engine robustness Resistance stress-testing Documentation Integration Tests Engines SDR Interface Specifications compliance Database SDR Interface Specifications compliance Automation Documentation Regression Tests (security checks / integration checks) Automation Documentation Backup System Backups Daily backups Weekly + Monthly rollovers Sources Bugtracker (JIRA) Version Control System (SubVersioN) Wiki (MediaWiki) Constraints Rapid development (2 days) Perl 5.8
Figure 22 - SDR-Tools Specifications

T EST IN G M AN AG EMEN T The Fonics system testing required a lot of interaction with the various teams and individuals working on the global system. Therefore, this project did not only imply technical difficulties but also managerial and hierarchical problems to overcome. Considering that some of the problems were not always software- but also specificationsrelated, it was often necessary to bounce back and forth between several O2 departments to get issues fixed as soon as possible, which required an insanely huge amount of time and effort, sometimes even calling for specifications to be rewritten or modified by another department. Because of the size of the project and of the numerous entities involved, it would often be necessary to wait for the next deployment of entire Fonic subsystems to be able to re-check raised issues and bugs.
Customer Care
SDR Interface SDR Sampling
O2Accounting
O2 (TNG)
CDRator
CDRator SDR Engines
Figure 23 - Fonic Joint Forces
O2-Service (TNG)
Rator Testing SDR Testing
T EST A UT OMAT ION In the light of the very limited time-resources allocated and authorized to the automation of the test-suites, it was decided to settle on the choice of a dynamic scripting language. Dynamic scripting languages, like Ruby, present a very fair advantage over more conventional programming languages as they tend to require smaller development teams and smaller development sessions. Combined with other languages, like for instance with JRuby that makes it possible to interface Ruby to a Java Virtual Machine, they become even more efficient as it allows the reuse of existing legacy libraries and frameworks for background tasks, such as: {European Institute of Technology.} 33
database management and persistence mapping logging networking
Using JRuby, a complete SDR-management framework was developed in record-time to automate or optimize testing sessions. This was made possible thanks to the capitalization on several factors: CDR/SDR Interfaces experience gained with the Nokia CDR-Tools project Conceptual design of the framework mapped on the Perl CDR-Tools Rubys speed and ease of development
The resulting SDR-Tools framework was used to build the following tools:
sdr_bulk sdr_check
generation of bulk SDR files for performance tests generation of scenario-based and/ordummy SDRs uses sdr_generate
identification and verification of SDR-files identification and verification of "in-database" SDRs
sdr_e2e
sdr_generate sdr_inspect sdr_lookup sdr_match
end-to-end testing suite performs tests through the complete SDR processing line
generation of scenario-based and/or dummy SDR-files generation of random SDR-files valid and invalid data support
validation and display of valid SDR-files text and raw SDR support
retrieval of remote "in-database" SDRs query language support
raw SDR files filtering (by keys, names, and field values) exclusion/inclusion and union/intersection support
sdr_send
sdr_spec sdr_tools
SDR-files FTP upload SDR-files renaming support
specifications-based syntaxic and semantic SDR checking automated database checking
set of convenience routines reused by all other tools SDR-repositories management text and raw SDR support
Figure 24 - SDR-Tools
Internship Report TNG Technology Consulting BACKUP A UT OMAT ION The automated backup solution was implemented using only Perl 5.8 core packages for portability reasons, so that the backup system can be used as standalone software and moved from a platform to another without worrying about any installation or setup procedures. Also, considering the very tight-schedule to implement this backup system at the end of the contract, a very minimalist but modular design. Thanks to this design, it allows future developers to extend its capabilities to other sources. As the backup sources management is completely abstract, it is possible to add support for other version control systems, other databases or other file-systems with a few minor modifications.
Automated Backup System
Backup Code Base
Documentation
Backup Script
Rollover Script
Daily Task
Weekly Task
Monthly Task
Figure 25 - Backup System Architecture
Regarding the automation of the backup tasks, those are performed at the operating systems level, using Scheduled Tasks on Microsoft Windows platforms or cron jobs on UNIX-variants. At the scheduled time, the Automated Backup System (ABS) will simply either perform a backup or a rollover, depending on its command-line arguments. It also logs its activity in a temporary log-file. Backup The ABS walks through its list of sources and, depending on their type, call the appropriate Backup Handler. Each Backup Handler falls back to a Directory Handler that will copy the resulting backups to a temporary directory and compress it. Upon successful compression, the backups are stored in an archiving directory with appropriate timestamps. Rollover The ABS lists the archive directory and keeps the latest backups of the week for a weekly rollover, and the latest of the month for a monthly rollover. The 20 most recent backups are stored, while the older ones are automatically removed. {European Institute of Technology.} 35
2.3.2.2. Results
The O2 Fonic passed its technical launch successfully on the 16th of March. It is currently in production and the first press-releases giving out its name are out. Its official real-life launch is scheduled for September 2007. At the end of the testing period, we obtained the following test-results matrix:
Performance
very heavy test-cases resulted in system slowdowns however, those tests should not and cannot happen in production
Robustness
Integration Regression
very heavy test-cases resulted in system crashes however, those tests should not and cannot happen in production
all tests have been successfully validated
all tests have been successfully validated Figure 26 - Fonic Testing Results
While it is noticeable that the system does not appear to be entirely bullet-proof, its performance and robustness met up with O2s expectations and requirements. The remaining problems and issues have been listed and documented, so that they will be taken into consideration by future Fonic upgrades or improvements of the CDRator Engines. Regarding the automated backup system, even though the schedule did not leave much time to implement a completely satisfying solution, it is completely sufficient to backup the testteams resources and allow for its recovery if a major crash were to occur.
3. Overall Timeline
Internship Start 2007.03.19 Technology Watch and Talks 2007.03.19 2007.04.13 Nokia CDR-Tools 2007.04.13 2007.06.26 DSL-Simulator 2007.06.11 2007.07.26 Fonic Testing 2007.07.16 2007.08.10 Internship End 2007.08.27
Figure 27 - Internship Timeline
Important Dates: 2007.03.19 EIT Internship Start Technology Watch o 2007.03.23 Talk: IT in China o 2007.04.13 Talk: Google Services O2 Projects o Nokia CDR-Tools 2007.04.13 Project Start 2007.06.26 Project Delivery 2007.07.27 Retrospective o DSL-Simulator 2007.06.11 Project Start 2007.06.26 Customer Feedback 2007.07.26 Project Delivery 2007.08.03 Retrospective o Fonic Testing 2007.05.01 Project Testing Kick-Off 2007.07.16 Reinforcements 2007.07.26 Team Restructuration 2007.08.16 Technical Launch 2007.08.20 Production Launch 2007.09.15 Customer Launch 2007.08.27 EIT Internship End 2007.12.31 Contract End
Conclusion
If all the projects exposed in this document are to be evaluated separately, it would come out of this overall analysis that each of them presented both really interesting and challenging objectives. They also came up, like every software development or management project, with their fair share of unexpected issues and complications. Briefly summed up, here are the projects and isolated tasks that were addressed and brought to fruition during this internship: technology watch assignments Involving small research & development as well as business intelligence tasks, they included: o analyzing and asserting Google Services o evaluating Wirecards financial and popularity status o giving lectures software development assignments Carried out on small-sized, middle-sized and nation-wide projects, they included: o developing a Call Data Record management framework and manipulation tools o extending a simulator for Digital Subscriber Line solutions o testing the interconnection between a complete mobile network solution and its Service Data Record Interface o developing a complete set of tools and libraries to automate the testing of a SDR Interface o implementing a custom automated backup system
All those assignments led to the use of several programming languages and frameworks, might they have been imposed by the customers requirements or a carefully thought-out decision. From a more personal perspective, it is here relevant to consider the value of both the knowledge and know-how that have been extracted over the last 6 months from the participation in relatively important enterprise software projects. Those tasks also often carried out cutting-edge tools and technologies, while requiring the application and enforcement of enterprise development techniques and best practices. The impact of the daily collaboration with groups of highly-skilled and experienced consultants represents also a net benefit in terms of education, both on the technical, professional and human levels. In addition to this, resorting to well-known market standards as well as emerging technologies for hands-on real-life software development greatly improved the already highly-technical challenge embodied by this internship. Finally, working for TNG provided a great opportunity to accumulate experience in a foreign country and to work in a multilingual environment. Considering all the realized projects and overcome issues, in contrast with the educational benefit of this journey, it is safe to declare this internship as a highly successful experience from the consultants perspective, and hopefully also from TNG Technology Consultings.
BIBLIOGRAPHY
Kaner, Bach, Pettichord. Lessons Learned in Software Testing. Thomas, Fowler, Hunt. Programming Ruby: The Pragmatic Programmers Guide. Burnstein. Practical Software Testing. Loveland, Miller, Prewitt, Shannon. Software Testing Techniques. Sommerville. Software Engineering. Knig, Glover, King, Laforge, Skeet. Groovy in Action. Wiley, 2001. Pragmatic, 2001. Springer, 2003. Charles River Media, 2004. Addison Wesley, 2006. Manning Publications, 2007.
GLOSSARY
{EPITECH.} AG
(see: EIT) Aktiengesellschaft (English : Corporation) Application Programming Interface A set of interface definitions (functions, subroutines, data structures or class descriptions) which together provide a convenient interface to the functions of a subsystem and which insulate the application from the minutiae of the implementation. Credit Card Call Data Record Contains data about a specific phone call, such as originating switch, terminating switch, call length and time of day. Code of Ethics A set of common-sense rules which define the ethical behavior of any individual. (Here: the obligations of any TNG employee) Document Object Model World Wide Web Consortium (W3C) standard for representing structured documents in a platform- and language-neutral manner. Digital Subscriber Line European Institute of Technology (see: http://www.epitech.net, http://www.eit.fr/) Process of assigning geographic coordinates (e.g. latitude longitude) to street addresses, as well as other points and features. With geographic coordinates, the features can then be mapped and entered into a GIS. Geographical Information System Gesellschaft mit beschrnkter Haftung. (English: similar to a LLC: Limited Liability Company) (see: http://bundesrecht.juris.de/gmbhg) GNU is a recursive acronym for "GNU's Not Unix". The GNU project was announced in 1983 by Richard Stallman with the goal of creating a complete Free Software operating system. Google Inc. (see: http://www.google.com/) Short for GNU zip, a GNU free software replacement for the UNIX compress program. Hyper-Text Markup Language Markup language designed for the creation of web pages and other information viewable in a browser.
HTTP
Hyper-Text Transfer Protocol Primary method used to convey information on the World Wide Web. The original purpose was to provide a way to publish and receive HTML pages. Institute of Management Consultants USA Information Technologies Encompasses all forms of technology used to create, store, exchange, and use information in its various forms Object-oriented programming language. Object-based scripting programming language based on the concept of prototypes. Java API for XML Processing A Java-embedded Ruby implementation Nokia (see: http://www.nokia.com/) (see: http://www.o2.com/, http://www.o2.de/) Scripting language Dynamic, fully object-oriented scripting language Simple API for XML Service Data Record Record type similar to a CDR, but containing service-relevant information. The Next Generation (as in TNG Technology Consulting GmbH) (see: http://www.tngtech.com/) World Wide Web Consortium Consortium producing the software recommendations for the World Wide Web. (see: http://www.w3.org/) Wirecard (see: http://www.wirecard.com/) eXtensible Markup Language A W3C-recommended, data-oriented general-purpose markup language for creating special-purpose markup language.
API
IMC USA IT
CC
Java
CDR
Javascript JAXP
CoE
JRuby
Nokia O2
DOM
Perl
DSL EIT
Ruby SAX
SDR
Geo-coding
TNG
GIS
GmbH
W3C
standards
qnd
GNU
Wirecard XML
Google GZip
HTML
XPath XML Path language A terse, non-XML syntax for addressing portions of an XML document.
APPENDIXES
A. Tables and Figures
FIGURE 1 - PARTNERS FIGURE 2 - BOARD OF DIRECTORS FIGURE 3 - DECISION-TAKING PRECEDENCE FIGURE 4 - CUSTOMERS TABLE 5 - SERVICES FIGURE 6 - ROUTE PLANNING DEMO WITH GOOGLE MAPS API TABLE 7 - GOOGLE APIS' COMPARATIVE RESULTS FIGURE 8 - WIRECARD ANALYSIS MINDMAP FIGURE 9 - TECHDAY TALK ABOUT THE IT IN CHINA FIGURE 10 - TECHDAY TALK ABOUT GOOGLE SERVICES FIGURE 11 - CDR ENCAPSULATION FIGURE 12 CDR BLOCK STRUCTURE FIGURE 13 - CDR-TOOLS SPECIFICATIONS FIGURE 14 - STANDARD CDR-TOOL WORKFLOW FIGURE 15 - NOKIA CDR TOOLS PROJECT ARCHITECTURE FIGURE 16 - RAW BINARY CDR FIGURE 17 - FORMATTED BINARY CDR FIGURE 18 - TEXT CDR FIGURE 19 - DSL-SIMULATOR REQUEST PROCESSING FIGURE 20 - SDR ENCAPSULATION FIGURE 21 - SDR BLOCK/FILE STRUCTURE FIGURE 22 - SDR-TOOLS SPECIFICATIONS FIGURE 23 - FONIC JOINT FORCES FIGURE 24 - SDR-TOOLS FIGURE 25 - BACKUP SYSTEM ARCHITECTURE FIGURE 26 - FONIC TESTING RESULTS FIGURE 27 - INTERNSHIP TIMELINE 10 10 10 12 13 15 17 19 21 21 23 23 24 25 26 27 27 27 28 31 31 32 33 34 35 36 37
B. Enterprise Documentation
B.1. Address
TNG Technology Consulting GmbH Betastrae 13a 85774 Unterfhring Germany
B.2. Legal Information

Managing directors: Henrik Klagges Gerhard Mller Christoph Stock Trade register: HRB 135082, Amtsgericht Mnchen Place of jurisdiction: Mnchen European VAT ID#: DE212842911 German tax ID#: 143/186/80621 DUNS number: 314309902
B.3. Services
Software Development
specification, implementation, delivery, test, operations, tuning, maintenance and troubleshooting language-/tool-agnostic implementation of business software on software-as-a-service platforms C/C++/Java on Unix and Windows including parallel supercomputers and clusters JEE/J2EE application servers like JBoss, WebLogic, Orion, Tomcat and WebSphere JSP, Servlets, JAXP, JMS, JNDI, RMI and JTA; plus OOA/D with UML and design patterns persistence layer, J/ODBC, CMP EJBs, object-relational mappers, distributed shared memory caches aspect-oriented programming with JBoss AOP and AspectJ inversion-of-control-frameworks such as Hivemind and Spring distributed systems with Corba, RMI, RPC, Session EJBs and Web Services (Axis, Glue) HTML, JavaScript and XML plus web application frameworks like Cocoon, JSF, Struts and Tapestry Shells, awk, sed, yacc/bison/JavaCC, f/lex Perl (mod_perl, CPAN, Mason, cgi) and PHP databases DB/2, mySQL, Oracle, PostGreSQL and SQL Server test-driven development with automated build systems code reviews, coaching and know-how transfer restructuring of ongoing third-party projects best practices and development processes such as RUP, SCRUM and XP particular domain knowledge in the areas of B2B portals, online finance and GIS
Administration & Operations

administration for all Unix flavours and Windows, service management with ITIL system management and kernel tuning network and service monitoring (Nagios, RRDtool, Grinder, Syslog, snoop/nettl/tcpdump, ethereal) backup with Networker, BackupPc, rsync, Dirvish und Symantec NetBackup cluster know-how HP MC ServiceGuard, Sun Cluster, LVS and Mosix email architecture with smtp, sympa, postfix, majorcool and majordomo firewalls like Raptor, Gauntlet, iptables and pf, routing with IOS, Lucent TOS, OSPF and BGP server technologies like Solstice disk suite and Veritas volume manager Mirror/UX, Ignite/UX, OnlineJFS, Glance configuration of automount, autofs, LDAP/OpenLDAP, NFS2/3, NIS, DNS, x/ntp core & crashdump analysis, systemcall traces with truss/tusc/ltrace/strace operation of Apache Webserver, Livewire, Cold Fusion content management systems like Drupal, OpenCMS and Typo3 system and network security analysis and tiger team-operations, intrusion detection public key infrastructures (PKI), best practices in cryptology, VPN (IPSec, OpenVPN
IT Management
IT strategy consulting project management and team leadership research and analysis of companies, products and technology concepts independant troubleshooting in critical situations coordination of external partner companies architecture, best practices and reviews training in all our areas of expertise
C. Technology Documentation
C.1. Used Programming Languages Progamming Language C/C++ Java Javascript (ECMAScript) Perl Ruby XML YAML Reference http://java.sun.com/ http://www.ecma-international.org/ http://perl.oreilly.com/ http://www.rubylang.org/ http://www.w3.org/ http://www.yaml.org/
Specific virtual machines and implementations are listed in the C.3. / C.4. C.2. Used Technologies Matrix Technologies J2EE SAX UML HTTP C.3. Used Softwares and Matrix Software ActivePerl CVS Eclipse Emacs Freemind JIRA JRuby MediaWiki Microsoft Office OpenOffice SubVersioN Reference http://www.activestate.com/ http://www.gnu.org/ http://www.eclipse.org/ http://gnu.org/ http://freemind.sf.net/ http://www.atlassian.com/ http://jruby.codehaus.org/ http://www.mediawiki.org/ http://www.microsoft.com/ http://www.openoffice.org/ http://subversion.tigris.org/ Reference http://java.sun.com/j2ee/ http://sax.sf.net/ http://www.uml.org/ http://www.rfcs.org/
C.4. Used Software Libraries and Frameworks Matrix Software JDOM Quartz Scheduler Emacs Freemind JRuby Microsoft Office OpenOffice Reference http://jdom.org/ http://quartz.sf.net/ http://gnu.org/ http://freemind.sf.net/ http://jruby.codehaus.org/ http://www.microsoft.com/ http://www.openoffice.org/ {European Institute of Technology.} 48
D. Samples, Studies, Analysis and Results

D.1. Nokia CDR-Tools
D.1.1. Sample Text CDR
Block 001 - CDR 001 (001) - hea ---------------------------------------record_length record_type charging_block_size tape_block_type data_length_in_block exchange_id first_record_number batch_seq_number block_seq_number start_time format_version : : : : : : : : : : : 0029 # 41 bytes 00 # Header record 01 # 0001 # 0A20 # 2592 bytes 49 17 60 00 00 04 FF FF FF FF # 27 10 00 00 # 00000157 # 0101 # 2007-04-11 08:09:34 # 38 61 04 01 04 FF #
D.2. DSL-Simulator
D.2.1. Sample Incoming Standard XML Request
<?xml version="1.0" encoding="UTF-8"?> <ns0:provisioningCommunicationActs xmlns:ns0=http://www.Telefonica.DE/markup/provisioning/general/> <ns0:baseMessage> <ns1:workflowData xmlns:ns1=http://www.Telefonica.DE/markup/provisioning/general-provisioning-data/> <ns1:workflowId>DSLIF1083WFL1152812090403</ns1:workflowId> <ns1:resellerId>156320</ns1:resellerId> <ns1:resellerWorkflowId>DSLIF.215:1152812090689</ns1:resellerWorkflowId> <ns1:answerUrl>https://deapvibf:48043/HttpsToHttpAdapter</ns1:answerUrl> <ns1:communicationDate>2006-01-01T00:00:00.000+00:00</ns1:communicationDate> </ns1:workflowData> </ns0:baseMessage> <ns1:lineOrderRequestMessage xmlns:ns1="http://www.Telefonica.DE/markup/provisioning/general-llu/"> <ns1:resellerSubscriberId>any_resellerSubscriberId</ns1:resellerSubscriberId> <ns1:subscriberData> <ns2:person xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> <ns2:naturalPerson> <ns2:surname>Surname</ns2:surname> </ns2:naturalPerson> </ns2:person> <ns2:address xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> <ns2:street>ADDR_Street</ns2:street> <ns2:houseNumber>1</ns2:houseNumber> <ns2:postalCode>12345</ns2:postalCode> <ns2:city>ADDR_City</ns2:city> </ns2:address> </ns1:subscriberData> <ns1:resellerOrderId>RETCSResellerOrderId</ns1:resellerOrderId> <ns1:currentOwnerData> <ns2:person xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> <ns3:naturalPerson xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> <ns3:surname>Surname</ns3:surname> </ns3:naturalPerson> </ns2:person> <ns2:address xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/">

<ns3:streetxmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> ADDR_Street </ns3:street> <ns3:houseNumber xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> 1 </ns3:houseNumber> <ns3:houseNumberAdd xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"/> <ns3:postalCode xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> 12345 </ns3:postalCode> <ns3:city xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> ADDR_City </ns3:city> <ns3:cityAdd xmlns:ns3="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"/> </ns2:address> </ns1:currentOwnerData> <ns1:product> <ns2:productType xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> ADSL2 </ns2:productType> <ns2:tariff xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> volume </ns2:tariff> <ns2:lineType xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> test </ns2:lineType> <ns2:bandwidth xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> <ns2:upStream>115200000000000000000</ns2:upStream> <ns2:downStream>2000094454545945948594859485945</ns2:downStream> </ns2:bandwidth> <ns2:interleaving xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> test </ns2:interleaving> <ns2:services xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> <ns2:voip>true</ns2:voip> <ns2:data>true</ns2:data> </ns2:services> </ns1:product> <ns1:tae>unknown</ns1:tae> <ns1:accountData> <ns2:userName xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> any_userName </ns2:userName> <ns2:userId xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-llu-complex/"> any_userId </ns2:userId> </ns1:accountData> <ns1:currentTalCarrier>D001</ns1:currentTalCarrier> <ns1:requestedDeliveryDate>2006-07-01+02:00</ns1:requestedDeliveryDate> <ns1:contractFile> <ns2:contractFileType xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> Tiff </ns2:contractFileType> <ns2:contractFileData xmlns:ns2="http://www.Telefonica.DE/markup/provisioning/general-common-complex/"> Vertrag </ns2:contractFileData> </ns1:contractFile> <ns1:remark>1</ns1:remark> </ns1:lineOrderRequestMessage> </ns0:provisioningCommunicationActs>
D.2.2. Sample Outgoing Standard XML Response

<?xml version="1.0" encoding="ISO-8859-1"?> <gep:provisioningCommunicationActs

xmlns:gep=http://www.Telefonica.DE/markup/provisioning/general/ xmlns:comb=http://www.Telefonica.DE/markup/provisioning/general-common-base/ xmlns:comc=http://www.Telefonica.DE/markup/provisioning/general-common-complex/ xmlns:com=http://www.Telefonica.DE/markup/provisioning/general-common/ xmlns:llub=http://www.Telefonica.DE/markup/provisioning/general-llu-base/ xmlns:lluc=http://www.Telefonica.DE/markup/provisioning/general-llu-complex/ xmlns:llu=http://www.Telefonica.DE/markup/provisioning/general-llu/ xmlns:pnbb=http://www.Telefonica.DE/markup/provisioning/general-pnb-base/ xmlns:pnbc=http://www.Telefonica.DE/markup/provisioning/general-pnb-complex/ xmlns:pnb=http://www.Telefonica.DE/markup/provisioning/general-pnb/ xmlns:pppb=http://www.Telefonica.DE/markup/provisioning/general-pppoe-base/ xmlns:pppc=http://www.Telefonica.DE/markup/provisioning/general-pppoe-complex/ xmlns:pppo=http://www.Telefonica.DE/markup/provisioning/general-pppoe/ xmlns:gepd=http://www.Telefonica.DE/markup/provisioning/general-provisioning-data/ xmlns:sipb=http://www.Telefonica.DE/markup/provisioning/general-sip-base/ xmlns:sipc=http://www.Telefonica.DE/markup/provisioning/general-sip-complex/ xmlns:sip=http://www.Telefonica.DE/markup/provisioning/general-sip/ xmlns:voib=http://www.Telefonica.DE/markup/provisioning/general-voip-base/ xmlns:voic=http://www.Telefonica.DE/markup/provisioning/general-voip-complex/ xmlns:voip=http://www.Telefonica.DE/markup/provisioning/general-voip/ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <gep:baseMessage gepd:schemaVersion="0.1.0"> <gepd:workflowData> <gepd:workflowId>%%workflowId%%</gepd:workflowId> <gepd:resellerId>%%resellerId%%</gepd:resellerId> <gepd:resellerWorkflowId>%%resellerWorkflowId%%</gepd:resellerWorkflowId> <gepd:resellerName></gepd:resellerName> <gepd:answerUrl>%%answerUrl%%</gepd:answerUrl> <gepd:communicationDate>%%communicationDate%%</gepd:communicationDate> </gepd:workflowData> <gepd:applicationAnswer> <gepd:code>200000</gepd:code> <gepd:message>OK</gepd:message> </gepd:applicationAnswer> </gep:baseMessage> <llu:lineOrderRequestAcknowledge> <comc:acknowledge>true</comc:acknowledge> </llu:lineOrderRequestAcknowledge> </gep:provisioningCommunicationActs>
D.2.3. Sample Incoming Simulator Command

<?xml version="1.0" encoding="UTF-8" ?> <SimulatorCommands> <SimResetWorkflow> <WorkflowId>RETCSResellerOrderIdACT33005803</WorkflowId> <WorkflowId>RETCSResellerOrderIdACT33005804</WorkflowId> </SimResetWorkflow> <SimTrigger> <FileName>lineTerminationByCarrierRequestMessage.xml</FileName> </SimTrigger> </SimulatorCommands>
D.3. Fonic
D.3.1. Sample Raw SDR
HDR200708020000000224000000000000 42 4651750852005405355508203571808720420101244242 42 4242 0 0 42 42 TRL200708020000000224000000100000
42 0 0 0
4917942424242
Internship Report TNG Technology Consulting D.3.2. Sample Text SDR

= 001 - 001 ========================================== name : Header Record fields : MD_RECORD_TYPE : HDR MD_CREATE_DATE : 20070802000000 MD_RECORD_SIZE : 0224 MD_NO_RECORDS : 0000000 MD_VERSION : 00000 MD_END_OF_RECORD : = 002 - 002 ========================================== name : Standard Record fields : MD_EVENT_RECORD_ID : MD_RECORD_SEQUENCE_ID : MD_EVENT_DATE : MD_EVENT_TYPE : MD_EVENT_RESULT : MD_USAGE_TYPE : MD_SP_ID : MD_MSISDN : MD_B_PARTY : MD_VOLUME_TYPE : MD_VOLUME_1 : MD_VOLUME_2 : MD_APPLICATION : MD_CONTENT_CLASS : MD_PROVIDER : MD_CATEGORY_ID : MD_COST_OF_EVENT : MD_MAIN_BALANCE : MD_DATE_EXPIRED : MD_BONUS_BALANCE : MD_BONUS_BALANCE_VALIDITY: MD_BONUS_BALANCE_USE : MD_VOUCHER_NUMBER : MD_END_OF_RECORD :
42 46517508520054053555082035718087 20420101244242
42 4917942424242 4 2 4 242 0 0 42 42 0 0 0
= 003 - 003 ========================================== name : Trailer Record fields : MD_RECORD_TYPE : TRL MD_CREATE_DATE : 20070802000000 MD_RECORD_SIZE : 0224 MD_NO_RECORDS : 0000001 MD_VERSION : 00000 MD_END_OF_RECORD :

Rapport

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport

Transféré par

Droits d'auteur :

Formats disponibles

{EPITECH.

} European Institute of Technology

TNG Technology Consulting Software Consulting

Laurent Malvert malver_l laurent.malvert@epitech.net

Internship Report TNG Technology Consulting

{European Institute of Technology.} II

Internship Report TNG Technology Consulting

SUMMARY 1. 2. 3. TNG TECHNOLOGY CONSULTING MISSION STATEMENT INTERNSHIP COMPLETION STAGES

BIBLIOGRAPHY GLOSSARY APPENDIXES

{European Institute of Technology.} III

Internship Report TNG Technology Consulting

{European Institute of Technology.} IV

Internship Report TNG Technology Consulting

{European Institute of Technology.} V

Internship Report TNG Technology Consulting

{European Institute of Technology.} VI

Internship Report TNG Technology Consulting

1. TNG Technology Consulting

{European Institute of Technology.} 7

3. Internship Completion Stages

{European Institute of Technology.} 8

Internship Report TNG Technology Consulting

The Enterprise: Branches, Activities & Customers

2. The Enterprise: TNG Technology Consulting

{European Institute of Technology.} 9

Internship Report TNG Technology Consulting

Figure 2 - Board of Directors

Partners Directors Consultants Interns

{European Institute of Technology.} 10

2.4. Code of Ethics

Our Obligations towards the Consultant-to-Customer Relationship

Our Obligations towards the Financial Integrity

Our Obligations towards the Openness and Reputation

{European Institute of Technology.} 11

Internship Report TNG Technology Consulting

3. Industry Sectors and TNG customers

a US student community an international linguistic services company

a UNIX server hardware manufacturer a specialized IT services provider

an international insurance company

{European Institute of Technology.} 12

Internship Report TNG Technology Consulting

4. Departments and Services

Project Management Project Office Analysis

5. The Position: Working as a TNG Software Consultant

{European Institute of Technology.} 13

Internship Report TNG Technology Consulting

{European Institute of Technology.} 14

Internship Report TNG Technology Consulting

1. TNG: Business Intelligence and Technology Watch

1.1. Google Services

1.1.1. Requirements 1.1.1.1. Objectives

{European Institute of Technology.} 15

{European Institute of Technology.} 16

Internship Report TNG Technology Consulting

Google Maps API

Google AdSense API

Solutions plethora Alternative Mapping Possible workarounds APIs Open-Source frameworks

{European Institute of Technology.} 17

Internship Report TNG Technology Consulting

1.2.1. Requirements 1.2.1.1. Objectives

1.2.2. Development Report 1.2.2.1. Realization

Figure 8 - Wirecard Analysis MindMap

{European Institute of Technology.} 19

Internship Report TNG Technology Consulting