Then we examine the use of TCP Port 20 for establishing TCP connections for directory transfer and file retrieval.

The complete sequence diagram can be divided into the following steps:

• DNS Query to obtain the IP address for the FTP Server
• FTP Telnet connection setup and login. (USER and PASS commands)
• Obtaining a directory listing (PORT and LIST command)
• Changing directory (CWD command)
• Downloading a file using FTP get (PORT and RETR command)

These phases are analyzed with sequence diagrams and context diagrams that provide multiple views of the FTP interactions.

FTP protocol sequence diagram

FTP High Level Overview

FTP control port (TCP port 21) handling

FTP data port (TCP port 20) handling

FTP context diagram

The sequence diagrams presented here were generated with EventStudio System Designer.

LTE X2 Handover

Full signaling details are presented here.

Overview

Now we examine the same flow at a higher level of abstraction. The diagram focuses on the interactions between the mobile, eNodeBs and the MME/SGW.

UE Interactions

We now explore the signaling procedures that involve the UE.

Source eNodeB Role

Examine the interactions that involve the eNodeB that initiated the handover.

Target eNodeB Role

We now look at the interactions involving the eNodeB that will be serving the UE after the handover.

RRC Signaling the X2 Handover

The Radio Resource Control (RRC) signaling between the UE and the eNodeBs is covered here.

X2AP Signaling Between eNodeBs

X2AP is used for signaling between the eNodeBs. Here we examine the X2AP interactions.

Data Path Changes During an X2 Handover

The data path switching goes through several steps to accomplish a seamless handover.

The messaging in X2 handover is detailed in LTE X2 Handover Presentation. A few excerpts from the presentation as shown below.

X2 Handover Sequence Diagram

The X2 handover flow is shown in the following sequence diagram:

Figure 1 X2 Handover Sequence Diagram

Handover Preparation

The handover procedure is triggered by the X2AP Handover Request message. The RABs to be handover over are sent from the source eNodeB to the target eNodeB.

Figure 2X2AP Handover Request

The target eNodeB then admits the user and responds with X2AP Handover Request Acknowledge message. This message contains a transparent container that carries the Handover Command message that needs to be sent to the UE.

Figure 3 X2AP Handover Request Acknowledge

The source eNodeB sends the handover command to the UE. It then sends sequence number information to the target eNodeB.

The target eNodeB then requests the MME to switch the path from the source eNodeB to target eNodeB.

Handover Execution

Figure 4 S1AP Path Switch Request

This was an overview of the messaging involved in the X2 handover. For details refer to the LTE X2 Handover Presentation.

New features in the release:

Message endpoint tagging

Specify tags

Tag the message source and destinations. This can be used to identify the endpoint port numbers, and specify the protocol layer or software entities.

	“BSSMAP PAGING”: A-bssmap -> B-bssmap
	HTTPGet : Client -> Server-“80″
	Cascade : A-rr -> B-cc -> C-“80″
	A-bcch multicasts SI to B-bcch, C-bcch
	Cascade : A-cc -> B-cc -> C-rr
	chain Chain1(par1,param2,param3):A-cc-> B-cc Chain2: B-cc -> C-rr endchain

Style tags

Each type of tag can be individually formatted. The color, font and font size may be specified. The styles for tags should be named as <tag>_tag_style. A few examples are shown below:

style rr_tag_style: color=RED, bgcolor=RED, textcolor=WHITE
style sccp_tag_style: color=DODGERBLUE, bgcolor=DODGERBLUE, textcolor=WHITE
style isup_tag_style: color=GREY, bgcolor=GREY, textcolor=WHITE
style bssmap_tag_style: color=MIDNIGHTBLUE, bgcolor=MIDNIGHTBLUE, textcolor=WHITE
style cc_tag_style: color=DARKSLATEGRAY, bgcolor=DARKSLATEGRAY, textcolor=WHITE
style bcch_tag_style: color=DODGERBLUE, bgcolor=DODGERBLUE, textcolor=WHITE
style “80_tag_style”: color=DODGERBLUE, bgcolor=DODGERBLUE, textcolor=WHITE

Tag specific diagrams

Use tags to filter and generate sequence diagrams that just contain messages with a specific tag.

Styling

Control the look and feel of documents with default styles. Automatically apply these styles that match regular expressions. For example, specify a style for all messages that start with specific text. Styles have been enhanced to change colors for the background, text, and parameters.

Group interactions with sequences

Simplified sequence definitions

Grouping interactions has been simplified. Just enclose the interactions in a sequence statement. EventStudio automatically identifies the interacting entities.

Nest sequences

Sequences may be nested. Quickly access a sequence from a PDF bookmark, which are nested too.

Collapse sequences

Complete sequences are shown the first time they occur in a sequence diagram.	Subsequent occurrences of the sequence are shown as a simple clickable box. Clicking on the box takes the user to the expanded sequence.

module: Module_01
component: Component_01 in Module_01
eternal: a in Component_01, b in Component_01, c in Component_01
feature "Sequence Grouping"
  sequence "Call Setup"
     IAM : a -> b
     b takes action "Check digits"
     ACM : a <- b
  endsequence
  case
     leg "Called Party Free":
       a, b take action "Set up the  voice path"
     leg "Called Party Busy": 
       a, b take action "Feed busy tone"
  endcase
  sequence "Call Release"
     REL : a -> b
     RLC : a <- b
  endsequence
endfeature

Classify systems with 5 levels of hierarchy

Generate sequence diagrams at any of the five abstraction levels.

Developers may work at the component and object level. System architects analyze the design at a system and subsystem level.

Improved modeling

Actions

Actions, which have a distinct beginning and ending, can be modeled with the new continuous action support. Also, actions may be specified at different levels in the hierarchy.

Messages

Lost messages can be modeled in sequence diagrams. Additionally, messages can be represented through a single simple statement.

“Lost Message”: A ->X B
“Message Cascade”: A -> B -> C

Enhanced tracing support

Flexible object interactions

Method invocation rules have been relaxed to make them compatible with sequence diagram generation from trace messages (http://eventhelix.github.com/trace-to-sequence-diagram/). Method calls to caller classes are permitted.

Command line

Command line mode is used to generate sequence diagrams from scripts. The command line can now be customized with specific conditional defines and include paths.

Model large systems

Share instance axes

Large number of interacting entities need not result in a large number of axis in diagrams. Dynamic objects can share a single instance axis, thus reducing the total number of axes needed in a sequence diagram.

Really large sequence diagrams

Sequence diagrams can now run into hundreds of pages. This is useful when converting large trace documents to sequence diagrams.

XML export

Export scenarios and interactions to XML. This enables generation of custom diagrams and documents.

We have covered call flows for an IMS to IMS and PSTN to IMS calls. We now look at the call flow for a IMS to PSTN subscriber call.

The call is routed via the BGCF (Border Gateway Control Function) to the MGCF (Media Gateway Control Function). The MGCF uses one context with two terminations in IM-MGW (Media Gateway). The termination RTP1 is used towards IMS Core network subsystem entity and the bearer termination TDM1 is used for bearer towards PSTN CS network element.

The call flow is complex and it is analyzed with multiple diagrams. Some of the diagrams are presented here:

A detailed call flow describing all message interactions in a IMS to PSTN call

A high level view that abstracts out individual component details and just presents the flow between the UE, IMS Core and the PSTN.

Here we examine the call flow from the UE point of view. The call flow is represented as a collaboration diagram.

Link: IMS subscriber to PSTN subscriber call flow

All documents:

• IMS to PSTN Call Flow
• IMS to PSTN Call Flow Poster (11×17)
• IMS to PSTN Call Overview
• IMS to PSTN Call Context Diagram
• High Level Flow (Calling UE-IMS-PSTN)
• High Level Flow (With CSCF and H.248 Details)
• IM-MGW Call Flow
• IM-MGW Context Diagram
• MGCF Call Flow
• MGCF Context Diagram
• BGCF Call Flow
• BGCF Collaboration Diagram
• Originating UE Call Flow
• Originating UE Collaboration Diagram

Optimizing C++ and C Code discusses several techniques that will help improve the performance.

1. Premature optimization is the root of all evil
2. Adjust structure sizes to power of two
3. Place case labels in narrow range
4. Place frequent case labels first
5. Break big switch statements into nested switches
6. Minimize local variables
7. Declare local variables in the inner most scope
8. Reduce the number of parameters
9. Use references for parameter passing and return value for types bigger than 4 bytes
10. Don’t define a return value if not used
11. Consider locality of reference for code and data
12. Locality of reference in multi-dimensional arrays
13. Prefer int over char and short
14. Define lightweight constructors
15. Prefer initialization over assignment
16. Use constructor initialization lists
17. Do not declare “just in case” virtual functions
18. In-line 1 to 3 line functions
19. Avoid cascaded function calls
20. Prefer preincrement over postincrement
21. Define move constructors in C++11
22. Use hardware accelerators and SIMD hardware
23. Use profile guided optimization

Rohde & Schwarz‘s presentations provide an excellent introduction to LTE. The presentations are accompanied with an audio narration. The topics covered are covered:

1. LTE Introduction
   • Motivations for LTE
   • LTE market and background
   • Requirements
   • Evolution path to LTE
2. LTE Parameters and Downlink Modulation
   • LTE parameters and frequency bands
   • What is OFDMA?
   • OFDMA multiple access and downlink frame structure
   • OFDMA transmit and receive chains
3. OFDMA and Downlink Frame Structure Details
   • Downlink OFDMA time-frequency multiplexing
   • LTE Spectrum Flexibility and Bandwidth
   • FDD downlink frame structure detailed
   • TDD frame structure
4. SC-FDMA and LTE Uplink
   • Introduction to SC-FDMA and uplink frame structure
     • Marriage of single carrier transmission and FDMA
   • Uplink SC-FDMA tranmsit and receive chains
   • Peak to Average Power Ratio (PAPR) comparison with SC-FDMA and OFDMA
5. Network and Protocol Architecture
   • LTE/SAE network architecture
   • EPC -Evolved Packet Core
   • Base Station control plane and user plane protocol stacks
   • EPC protocol stacks
6. Channel Mapping and UE Categories
   • Logical and transport channel mapping in downlink and uplink
   • LTE UE Categories
7. Initial Cell Search and Cell Selection
   • Downlink physical channels and signals
   • Cell Search and Selection in LTE
     • Primary synchronization signal
     • Secondary synchronization signal
     • Reference signals
8. System Information
   • Downlink reference signal details
   • Master Information Block on PBCH
   • System Information on DL-SCH
9. Random Access Procedures and EPS Bearer Setup
   • Random access preamble transmission to eNodeB
   • Random access response from eNodeB
   • Resource allocation and contention resolution
   • Signaling on PDCCH
   • Hybrid ARQ
   • RRC Connection Setup and EPS Bearer Setup
10. Uplink Channels and Signals
    • Uplink physical channels and signals
    • PU-SCH: Physical Uplink Shared Channel
    • Uplink assignment signaling on PDCCH
    • Uplink frequency hopping
    • PUCCH
11. LTE Mobility and MIMO Introduction
    • Intra MME Handover over the X2 interface
    • RRC States
    • MIMO Basics
      • Transmit diversity
      • Spatial multiplexing
      • Beamforming
12. Downlink and Uplink MIMO in LTE
    • Downlink MIMO modes
      • Transmit diversity
      • Spatial multiplexing
      • Cyclic delay diversity
      • Beam forming
    • Spatial multiplexing downlink transmitter chain
      • Code book based precoding
    • Uplink MIMO
      • Uplink transmit antenna selection
      • Multi-user MIMO
13. eNodeB and UE Performance Requirements
    • eNodeB modulation quality measurements
    • eNodeB performance requirements
    • UE performance requirements
14. UE Certification and Field Trials
    • LTE terminal testing stages
    • LTE terminal certification
    • LTE field trial scenarios

PSTN to IMS call flow

This call flow covers the handling of a CS network originated call with ISUP. In the diagram the MGCF requests seizure of the IM CN subsystem side termination and CS network side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. Originating and terminating end initiated call releases are also covered.

The following sequence is covered:

1. ISUP IAM Handling and Initial IM-MGW and MGCF (Mn) Interactions
   
2. Initial Handshake between MGCF and IMS CSCF Servers
3. Mn Interactions for Codec selection
4. ISUP ACM related interactions on Mn interface
5. IMS Answer to ISUP ANM Handling
6. Conversation Mode
7. Call Release:
   • Calling PSTN Subscriber Initiated Call Release
   • Called Subsciber Initiates Call Release

Link: PSTN subscriber to IMS call flows

Focus on different aspects of the call flow

PSTN to IMS call is a very complex flow. The main sequence flow is supplemented with flows that focus on a particular aspect of the flow. A snapshot of one such diagrams is shown here:

Link: PSTN subscriber to IMS call flows

• Changing the the order of header files often results in difficult to track compilation errors
• C++ project compilations take a long time due to complex header file inclusions

Here are a few rules to remedy this:

• A header file should be included only when a forward declaration would not do the job.
• The header file should be so designed that the order of header file inclusion is not important.
  • This is achieved by making sure that x.h is the first header file in x.cpp
• The header file inclusion mechanism should be tolerant to duplicate header file inclusions.

An example of illustrates the header file inclusion rules:

Header file

#ifndef _a_h_included_
#define _a_h_included_
#include "abase.h"
#include "b.h"

// Forward Declarations
class C;
class D;

class A : public ABase
{
  B m_b;
  C *m_c;
  D *m_d;

public:
  void SetC(C *c);
  C *GetC() const;

  void ModifyD(D *d);
};
#endif

Source file

#include "a.h"
#include "d.h"

void A::SetC(C* c)
{
  m_c = c;
}

C* A::GetC() const
{
  return m_c;
}

void A::ModifyD(D* d)
{
  d->SetX(0);
  d->SetY(0);
  m_d = d;
}

For details, refer to: C++ Header File Include Rules

This blog post is based on the article mapping from C++ inheritance and virtual functions to C code. The contents of the article are summarized below.

Mapping a base class with virtual functions to C

A C++ base class with virtual functions requires extra logic to support the machinery for handling virtual functions. The following C++ base class….

class Shape
{
protected:
  int m_x;
  int m_y; 

public:
  virtual void Draw() = 0; 
  virtual void MoveTo(int newX, int newY);
  void Erase();
  Shape(int x, int y);
  virtual ~Shape();
};

…maps to the following C code.

typedef void (*VirtualFunctionPointer)(...);

struct VTable
{
   int d;  /* d and i are used in multiple inheritance */
   int i;
   VirtualFunctionPointer pFunc;
};

VTable VTableArrayForShape[] =
{
    { 0, 0, (VirtualFunctionPointer) pure_virtual_called_error_handler },
    { 0, 0, (VirtualFunctionPointer) Shape_MoveTo },
    { 0, 0, (VirtualFunctionPointer) Shape_Destructor }
};
struct Shape
{
  int m_x;
  int m_y;
  VTable *pVTable;
};

Points to note here are:

• VTable structure used by the compiler to keep track of the virtual functions associated with a class.There is one instance of a VTable for every class containing virtual functions. All instances of a given class point to the same VTable.
• The C++ compiler inserts an extra pointer to a vtable which will keep a function pointer to the virtual function that should be called.
• The VTable pointer in the base class points to an array of VTables. The number of entries in the array of VTables depends upon the number of virtual functions in the class.
• Note that a pure virtual function maps to function that will result in an exception.

For details refer to the article: Mapping from C++ inheritance and virtual functions to C code

Mapping an inherited class with virtual functions to C

The inheriting Circle class….

class Circle : public Shape
{
private:
   int m_radius;    // Radius of the circle

public:
   // Override to draw a circle
   virtual void Draw();   

   // Constructor for Circle
   Circle(int x, int y, int radius);

   // Destructor for Circle
   virtual ~Circle();
};

…maps to a new VTable array and a new struct:

VTable VTableArrayForCircle[] =
{
    { 0, 0, (VirtualFunctionPointer) Circle_Draw },
    { 0, 0, (VirtualFunctionPointer) Shape_MoveTo },
    { 0, 0, (VirtualFunctionPointer) Circle_Destructor }
};

struct Circle
{
   /* Fields inherited from Shape */
   int m_x;
   int m_y;
   VTable *pVTable;

   /* Fields added by Circle */
   int m_radius;
};

• The inheriting class preserves structure offsets for inherited base class fields and the VTable array pointers.
• A new VTable array is defined for the inherited class.
  • The pure virtual function entry has now been replaced with a call to Circle’s Draw function.
  • The entry for a function that is not being inherited is preserved (Shape’s MoveTo)
  • Shape class has a virtual destructor. The destructor vtable entry now points to Circle’s destructor.

For details refer to the article: Mapping from C++ inheritance and virtual functions to C code

Mapping a virtual function call to C code

A virtual function call like…

 pShape->Draw();

…is replaced by a call through a virtual table function pointer.

  (pShape->pVTable[0].pFunc)(pShape);

Explore More

We have covered basics of inheritance handling here. For details about constructor and destructor definitions and vtable array pointer initialization refer to the article:  Mapping from C++ inheritance and virtual functions to C code.