Technology explained

UDTP pre-specification

UDTP (Up/Down Trans­port Pro­to­col) is a trans­port lay­er pro­to­col that con­tains mech­a­nisms for ensur­ing trans­mis­sion qual­i­ty with guar­an­teed deliv­ery in pack­et-based net­works with an explic­it­ly orga­nized con­nec­tion.

UDTP pro­vides the fol­low­ing types of ser­vices for apps:
  • band­width allo­ca­tion with trans­mis­sion laten­cy con­trol;
  • ordered deliv­ery of user data;
  • guar­an­teed data deliv­ery;
  • asym­met­ri­cal (up/down) data trans­mis­sion;
  • mul­ti­plex­ing / de-mul­ti­plex­ing of user data;
  • sup­port of for­ward error cor­rec­tion in data trans­mis­sion;
  • data encryp­tion sup­port dur­ing trans­mis­sion;
  • data trans­fer sup­port in the form of a file, stream or mes­sage;
  • resilience to fail­ures and changes on the net­work lev­el;
  • mobile users sup­port;
  • sup­port for mul­ti­cast and broad­cast con­nec­tions on both sides;
  • no dupli­cates dur­ing data deliv­ery;
  • real-time and time-insen­si­tive data trans­fer sup­port in a sin­gle com­mu­ni­ca­tion chan­nel.

UDTP is an inte­grat­ed part of IPv17 net­work mod­el (see Fig­ure 1), which dif­fers from the ref­er­ence mod­el of open sys­tems inter­con­nec­tion (ITU X. 200).

Fig­ure 1. IPv17 net­work mod­el.

Picture 1. IPv17 network model

IPv17 net­work mod­el con­sists of two lay­ers: data lay­er and com­mu­ni­ca­tion lay­er, each of them con­tains three lev­els and two inter­faces.

The dif­fer­ence between IPv17 net­work mod­el and ISO/OSI sev­en-lay­er ref­er­ence mod­el is that the data lay­er at the stage of estab­lish­ing a con­nec­tion defines the par­tic­i­pants of data inter­ac­tion and sets the con­nec­tion para­me­ters required for data trans­mis­sion and the com­mu­ni­ca­tion lay­er main­tains the con­nec­tion with the giv­en para­me­ters.

Network model — data layer, application level
The appli­ca­tion lev­el, to ensure data exchange:
  1. per­forms iden­ti­fi­ca­tion, ini­tial­iza­tion, acti­va­tion and deac­ti­va­tion of a net­work appli­ca­tion;
  2. syn­chro­nizes net­work appli­ca­tions activ­i­ties;
  3. spec­i­fies a type and para­me­ters of trans­mit­ted data.
Network model — data layer, presentation level

The pre­sen­ta­tion lev­el coor­di­nates a trans­ferred data for­mat (e.g. an order of bits trans­mis­sion first of all).

Network model — data layer, session level
The ses­sion lev­el, to ensure data exchange:
  1. search­es for par­tic­i­pants;
  2. iden­ti­fies par­tic­i­pants;
  3. estab­lish­es a con­nec­tion between data exchange par­tic­i­pants and pro­vides a con­nec­tion sup­port;
  4. can tar­iff the con­nec­tion;
  5. defines the FEC set­tings of data exchange in the com­mu­ni­ca­tion link;
  6. defines cryp­to­graph­ic para­me­ters the con­nec­tion for data exchange;
  7. car­ries out dig­i­tal rights con­trol dur­ing data exchange.
Network model communication layer

The com­mu­ni­ca­tion lay­er imple­ments the data exchange through the trans­fer of data between the par­tic­i­pants, uses for this: net­work, trans­port, phys­i­cal lev­els and a com­mu­ni­ca­tion inter­face (Pro­to­col stack).

Network model — communication layer, network level

The net­work lev­el estab­lish­es, main­tains, and restores, if nec­es­sary, the route of data trans­fer between end sys­tems with regard to the required con­nec­tion type accord­ing to net­work ID (NetID).

The net­work lev­el per­forms rout­ing process­es, for this builds, main­tains, restores and removes the routes for mobile and fixed con­nec­tions in a net­work with a sta­t­ic or dynam­ic topol­o­gy.

Safe­ty and reli­a­bil­i­ty main­tain routes are pro­vid­ed by a tab­u­lar-unbound method of estab­lish­ing a route, elim­i­nat­ing the need for rout­ing pro­to­cols.

Pro­tec­tion of the net­work iden­ti­fi­er NetID from chang­ing, block­ing or delet­ing dur­ing the con­nec­tion life­time is pro­vid­ed by net­work lev­el, for this inserts forced­ly sender net­work iden­ti­fi­er NetID in each pack­et of trans­mit­ted data which was select­ed when estab­lish­ing the con­nec­tion.

Network model — communication layer, transport level

The trans­port lev­el solves the prob­lem of data trans­fer­ring through the trans­mis­sion medi­um with the para­me­ters that are set at the appli­ca­tion lev­el.

The trans­port lev­el gen­er­ates a deter­min­is­tic access dis­ci­pline to the trans­mis­sion medi­um, imple­ments, accord­ing to the estab­lished con­nec­tion between the end sys­tems, the process of data trans­fer­ring, for this frag­ments trans­mit­ted data into data pack­ets, trans­mits the data pack­ets to the com­mu­ni­ca­tion chan­nel in the form of pack­ets and receives pack­ets from the com­mu­ni­ca­tion chan­nel, process­es the data pack­ets and assem­bles the received data pack­ets in the form of file, stream or mes­sage.

 The dis­ci­pline of wired or wire­less com­mu­ni­ca­tion chan­nels of the trans­mis­sion medi­um allows for the data trans­fer set­tings.

Network model — communication layer, physical level

Phys­i­cal lev­el acti­vates, main­tains and deac­ti­vates a data trans­mis­sion chan­nel. The phys­i­cal lev­el imple­ments access dis­ci­pline to the trans­mis­sion medi­um, deter­mines ten­sion lev­els and syn­chro­nizes changes of ten­sions, sets the trans­mis­sion rate of mes­sages, per­forms error pro­tec­tion meth­ods, encryp­tion meth­ods (if nec­es­sary), mod­u­la­tion meth­ods, and mechan­i­cal con­nec­tions and oth­er sim­i­lar func­tions.

UDTP basic principles

UDTP for orga­niz­ing of data trans­fer uses:
  1. net­work ID – NetID,
  2. trans­mis­sion mech­a­nism – Net­D­MA,
  3. a method of data trans­mis­sion qual­i­ty assur­ance – BrD&J.

The data structure of UDTP — NetID

NetID is a user iden­ti­fi­er.

With­in IPv17 net­work envi­ron­ment, UDTP takes a net­work iden­ti­fi­er (NetID) from the net­work enti­ty and per­forms NetID reg­is­tra­tion pro­ce­dure in the switch­ing node.

UDTP keeps the NetID reg­is­tra­tion in the NetID switch­ing node data­base. The pro­ce­dure of NetID reg­is­tra­tion in the switch­ing node data­base may use two or more modes:
  • no attrib­ut­es,
  • one attribute, for exam­ple, PIN,
  • two attrib­ut­es, that
  • two attrib­ut­es and the attrib­ut­es con­fir­ma­tion from an exter­nal source.

Net­work iden­ti­fi­er (NetID) includes the num­ber, name, and alias of a user. The size of net­work ID (NetID) can not be more than 256 octets and may have the fol­low­ing struc­ture:

struct NetID {
  uint64 type:4,
         number:60;
  char[127]  *name;
  char[115]  *nic;
  uint32 crc32;
}

NetDMA data transfer mechanism

Ser­i­al trans­mis­sion using the Net­D­MA is based on the method of dynam­ic time mul­ti­plex­ing with a changed order of the head­er and the body of the data pack­et and it is called “body for­ward”.

The for­ma­tion of data pack­ets allows stop­ping trans­mis­sion of the pack­et body into the com­mu­ni­ca­tion chan­nel at any point of time main­tain­ing the integri­ty of data deliv­ery. The integri­ty of the data pack­et deliv­ery is based on a ver­i­fi­ca­tion code (CRC-32).

Data packet

The data pack­et is a con­tain­er for data trans­fer. The data pack­et con­sists of a body and a head­er. The pack­et body con­tains the pay­load of the trans­mit­ted data and the head­er con­tains ser­vice infor­ma­tion includ­ing infor­ma­tion about the integri­ty of trans­mit­ted data.

A pack­et trans­mis­sion is car­ried out in two stages. First­ly, a pack­et body is sent into a chan­nel, and then the pack­et head­er with a gap. The head­er con­tains infor­ma­tion about the integri­ty of the trans­fer pack­et body, which includes the length of the trans­mit­ted part of the body and the ver­i­fi­ca­tion code (CRC-32).

The pack­et body has a vari­able length, and the pack­et head­er has a fixed length depend­ing on the type of the head­er.

Data packets transmission

This para­graph is skipped because it is in a process of patent­ing.

NetDMA method implementation

Net­D­MA is imple­ment­ed as a dri­ver and uses the DMA device that is avail­able for each proces­sor or micro­con­troller but dif­fers because it uses DMA not only for data trans­fer­ring but also direct­ly for form­ing a data pack­et, free­ing the CPU from this task. This imple­men­ta­tion sig­nif­i­cant­ly reduces the load on the CPU while trans­mis­sion of data pack­ets.

BrD&J mechanism of data transmission quality support

UDTP sup­ports BrD&J mech­a­nism (Bitrate, Delay & Jit­ter) to estab­lish data trans­fer qual­i­ty para­me­ters, includ­ing band­width allo­ca­tion, spec­i­fies the type of delay and main­te­nance the delay vari­a­tion (jit­ter) with­in a pre­de­ter­mined range.

UDTP sup­ports the exe­cu­tion of user’s appli­ca­tion require­ments by:
  1. band­width allo­ca­tion for the con­nec­tion
  2. set­ting laten­cy con­trol mode while data trans­fer.
Bandwidth allocation

The band­width allo­ca­tion deter­mines how many bits must be trans­mit­ted per time unit. Band­width should be mea­sured by bps (bit per sec­ond).

Type of delay

With­in the trans­mis­sion cycle or with­out regard to the trans­mis­sion cycle.

The first one is used for real-time traf­fic, the oth­er one is used for time-insen­si­tive traf­fic.

Time axis”

UDTP cre­ates or uses a “Time axis” for the pur­pose of form­ing a trans­mis­sion rate which is pre­de­ter­mined by an appli­ca­tion. “Time axis” is a trans­fer of a pre­de­ter­mined syn­chro­niz­ing sequence in the form of “Ping” pack­et or “Sync Code” to estab­lish the start­ing point of the trans­mis­sion cycle.

The cycle val­ue is set by Channel_time_loop para­me­ter which is in the con­fig­u­ra­tion file.

“Time axis” syn­chro­niz­ing sequence can be trans­mit­ted in two modes:
  1. between user’s appli­ca­tions;
  2. between points that orga­nize the phys­i­cal com­mu­ni­ca­tion chan­nel.

The first mode may be used to per­form “Time axis” syn­chro­niza­tion func­tion between user’s appli­ca­tions when the con­nec­tion is estab­lished by IPv4 and IPv6 infra­struc­ture. The sec­ond mode may be used for estab­lish­ing IPv17 infra­struc­ture con­nec­tion.

The formation of the “Time axis”
UDTP ensures require­ments imple­men­ta­tion user’s appli­ca­tion:
  1. to allo­cate band­width for the con­nec­tion,
  2. to set a laten­cy con­trol mode dur­ing data trans­fer,

for that cycli­cal­ly gen­er­ates a “time axis” syn­chro­niz­ing sequence for the pur­pose of imple­ment­ing the mech­a­nism for band­width allo­ca­tion and laten­cy con­trol with guar­an­teed jit­ter for spec­i­fied lim­its.

Time axis” is formed by the peri­od­ic send­ing a spe­cial Ping-pack­et.

Fig­ure 2. “Time axis” mode of the inter­face.

Picture 2. Time axis mode of the interface

Fig­ure 3. “Time axis” mode of the appli­ca­tions.

Figure 3. Time axis mode of the applications

The allo­ca­tion (reser­va­tion) of band­width is per­formed only dur­ing the data trans­mis­sion at the con­nect­ing moment. Request­ed resources are released upon com­ple­tion of the con­nec­tion.

The net­work topol­o­gy changes should lead to the restora­tion of the trans­mis­sion chan­nel, with­out a request for the appli­ca­tion to close the chan­nel.

The user’s tran­si­tion between the com­mu­ni­ca­tion nodes (han­dover mode) may result in the reg­is­tra­tion of the net­work iden­ti­fi­er at the oth­er com­mu­ni­ca­tion node, but it is allowed send­ing reg­is­tra­tion data between com­mu­ni­ca­tion nodes.

Client/server relationship

Client/server rela­tion­ship chart is pre­sent­ed (see Fig­ure 4).

Fig­ure 4. Client/server rela­tion­ship.

Рисунок 6. Диаграмма состояний

UDTP fields

NetID и UDTP

Fig­ure 5. First pack­et – con­nec­tion estab­lish­ing.

Figure 5. First packet – connection establishing

Fig­ure 6. Sec­ond and next pack­ets – data trans­fer.

Figure 6. Second and next packets – data transfer

Data transfer by UDTP

Data transmission recovery

Data trans­fer may be accom­pa­nied by loss­es. UDTP can imple­ment lost data recov­ery by re-trans­mit­ting of a part of data or orga­niz­ing a ser­vice pack­et with proac­tive FEC error codes. Trans­port pro­to­col deter­mines a recov­ery method.

Re-transmission

UDTP can arrange pack­ets re-trans­mis­sion by accept­ing a con­fir­ma­tion attribute of each received pack­et or of each pack­et with detect­ed loss­es.

UDTP allows data trans­fer with­out receiv­ing a con­fir­ma­tion attribute of the accept­ed data pack­et.

Data re-trans­mis­sion uses an aux­il­iary con­nec­tion. Orga­niz­ing of pack­et re-trans­mis­sion allows to stop data trans­mis­sion on the pri­ma­ry con­nec­tion or with­out stop­ping but using a dif­fer­ent trans­mis­sion rate with­in the over­all pre­scribed band­width in the chan­nel.

The size of the data pack­et to repeat is deter­mined by two points that obtained in “Bor­der file” field while receiv­ing ‘i’ and ‘i+1’ data pack­ets. The val­ue of the two points is trans­mit­ted by two head­ers in aux­il­iary and ser­vice con­nec­tion.

UDTP features

UDTP fea­tures include:
  1. a clear indi­ca­tion of the used appli­ca­tion Pro­to­col, miss­ing the port num­ber and there is no pos­si­bil­i­ty to change the num­ber of the Pro­to­col when the con­nec­tion is estab­lished;
  2. while estab­lish­ing a con­nec­tion it is per­formed a pro­ce­dure of user’s NetID iden­ti­fi­ca­tion, that
    1. receiv­ing a data pack­et does not allo­cate mem­o­ry to process the con­nec­tion,
    2. estab­lish­ing the con­nec­tion fix­es the Pro­to­col num­ber, trans­mis­sion rate and NetID that can­not be changed while a data tran­si­tion process
    3. and each data pack­et has an iden­ti­fi­ca­tion field that allows iden­ti­fy­ing pack­ets that are trans­ferred between the end­points of the con­nec­tion;
  3. four threads are cre­at­ed while orga­niz­ing a con­nec­tion: pri­ma­ry, ser­vice, con­trol and sta­tis­ti­cal, up to 32 con­nec­tions can be arranged between the end points;
  4. four streams are used for:
    • data is trans­mit­ted on the pri­ma­ry stream,
    • rep­e­ti­tion is trans­mit­ted on the ser­vice stream,
    • band­width con­trol, coor­di­nat­ing of FEC encod­ing and encryp­tion are per­formed on the con­trol stream,
    • chan­nel load­ing data and con­nec­tion data are trans­mit­ted on the sta­tis­ti­cal stream;
  5. direct and return chan­nels are inde­pen­dent of each oth­er and can sup­port dif­fer­ent trans­mis­sion rates;
  6. the pro­to­col has a mul­ti-path trans­mis­sion mode which is used either to improve the reli­a­bil­i­ty of trans­mis­sion or to increase band­width.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.