Networking — Something Good to Know

February 24, 2014

Programming Languages for Cloud Computing — A brief comparison

Filed under: Uncategorized — conningtech @ 9:22 pm

1. Overview

Cloud computing has special requirements to the programming languages:

  • Multi-platform programming: Cross-Platform/Cross-OS
  • Multi-paradigm programming: –Object Oriented Programming and Functional Programming
  • Distributed Parallel computing: –Concurrence, –Event-driven
  • Programming at Scale: –Readability, Modularity, Speed of compilation, Suitable for large team, Meta-programmability and extensibility, Concise
  • Client side programming: –Replacement for JavaScript (?), –Same language for both client and server side
  • –run on multiple client platforms
  • Publically available libraries
  • Performance
  • Fault-tolerance/Self-healing

2. Options

2.1 Server Side
  • Existing mutual languages: –C/C++, Good performance, but platform dependent, Java, C#, PHP, Platform independent, development complicity, JavaScript (Node.js), Shell script, Perl, Python, Ruby, Objective-C, Erlang, Platform independent, Concise.
  • New potential languages: Ceylon , Opa, Fantom, X10, haXe, Clojure, Scala, Groovy, compile to Java / JVM bytecode (all) and to –PHP, C++ etc. (some of them), Go, Chapel, Zimbu, compile to Binary or C / ANSI C, F# compiles to .NET
2.2 Client Side
  • Existing mutual languages: JavaScript
  • New potential languages: Dart, compiles to Dart VM executable, Zimbu, compile to ANSI C, Ceylon, F#, Opa, Fantom, haXe, Clojure, all compile to JavaScript.

3. New Language Comparison

Language Vendor Primary Driver Features use Runs On Licensing
Ceylon Red Hat Readability, Predictability, Tool-ability, Modularity, Meta-programmability.

bridging the gap between client and server

can be compiled to JavaScript

Java’s syntax

fully interoperable with Java and the Java SDK.

operator polymorphism

No operator overloading

Client

Server

JVM

JavaScript VM

GPL v2
Chapel Cray Programmability of parallel computers Compiles to C codes Server Cray supercomputers various high-performance clusters. Portable to most Unix-style systems, Mac OS X and Windows BSD
Clojure Rich Hickey Concurrency using Functional programming paradigm. compiles directly to JVM bytecode

ClojureScript compiles Clojure to JavaScript

easy access to the Java frameworks

a dialect of Lisp

a functional programming language

JVM-based derivatives

Client?

Server

JVM, CLR, JavaScript engines EPL
DART google A replacement for JavaScript on the browserFaster, easier to maintain, and less susceptible to subtle bugs.Dart VM needs to be compiled ultimately to replace JavaScript

cross-compilation to JavaScript

class-based single inheritance object-oriented language with C-style syntax

Client Dart VM,

DVM chrome

Linux, Mac and Windows

New BSD
Language Vendor Primary Driver Features use Runs On Licensing
F# Microsoft Multi-paradigm: Functional + Imperative + Object-oriented. Can be executed as a .NET code on the server and as JavaScript code on the client-side Client

Server

CLR and Mono

 

Apache
Fantom Brian Frank, Andy Frank Portability, support for functional programming and concurrency. compiles to javaScript. Future targets might include Objective-C

portable to the Java VM, .NET CLR, and JavaScript in the browser

Client

Server

JVM and CLR. Academic Free License
Go Google Compiled with the ease of programming of a dynamic language, concurrency and communication, speed of compilation. Compiler available for Linux, Mac OS X, Windows Compiles to binary executable Server   BSD style + patent grant
haXe Nicolas Cannasse Multi-platform support. Compiles to JavaScript, Flash, NekoVM, PHP, C++. C# and Java support is expected Server

Client

  GPL v2
Language Vendor Primary Driver Features use Runs On Licensing
Opa MLstate Targeted for cloud computing. Client-side UI, server-side logic, and database I/O are all implemented in a single language Runtime environment own Web server and DBMS. compiled to Nodejs on the server and JavaScript on the client Client

Server

 

64-bit Linux and Mac AGPL
Scala EPFL Scalability for multi-core and distributed computing. For large team. Multi-paradigm: Functional and Object-Oriented. Extensible.

 

Seamless Java Interop

 

compiles to Java bytecode

 

JVM-based derivatives

Server JVM, Android, CLR BSD
Groovy James Strachan  object-oriented programming language for the Java platform compiles to JVM bytecode, and interoperates with other Java code and libraries. Server

 

JVM Apache v2
X10   Designed specifically for parallel programming, performance and scale. Compiles to C++, Java, Native Binary Executable, Java bytecode Server Runs on IBM AIX, Linux, Mac OS X, Windows EPL
Zimbu Bram Moolenaar Aims to be fast, concise, portable, and easy-to-read and support  GUI application to an OS kernel. Compiles to ANSI C Client

Server

  Apache v2
Advertisements

2013 webRTC expo: Looking forward and getting prepared

Filed under: Uncategorized — conningtech @ 4:00 pm

2013 webRTC expo: Looking forward and getting prepared, here are what to focus on WebRTC-2013 look forward and get prepared

2013 webRTC Expo: Products and Services

Filed under: Uncategorized — conningtech @ 3:58 pm

2013 webRTC Expo: Products and Services from major vendors are presented in WebRTC-2013 services and products

2013 webRTC Expo: The Big Picture and Keynotes Highlights

Filed under: Uncategorized — conningtech @ 3:05 pm

2013 webRTC Expo: The Big Picture and Keynotes Highlights — WebRTC-2013 Big Picture and Keynotes

2013 webRTC Expo Notes Abstract

Filed under: Uncategorized — conningtech @ 3:02 pm

Attended 2013 webRTC Expo. Notes abstracted as in the attached presentation: WebRTC-2013 abstract

January 8, 2014

webRTC for online store application

Filed under: Uncategorized — conningtech @ 9:00 pm

webRTC for online store applications

DPI Based Intelligent network traffic routing

Filed under: Uncategorized — conningtech @ 8:59 pm

DPI based intelligent network traffic routing

Enhanced Voice Mail Services

Filed under: Uncategorized — conningtech @ 8:52 pm

1.      Existing voice mail services overview

  • PSTN/wireless/VoIP/etc. users who subscribed “voicemail” service can direct incoming calls to voicemail system based on preference (e.g. on busy line etc.)
  • Calls directed to voicemail system are recorded and saved in voice system, and voicemail waiting indicator is delivered to the user’s device or email account via SMDI/Skinny Call Control Protocol, SMS, email etc.
  • Users can access their voicemail accounts via phone, email, web and so on to listen, manage and delete stored voicemails.

2.      Enhanced voice mail services/capabilities

  • Introduced voicemail class/category/priority/treatment indications: voicemail sender is allowed and prompted to specify the class/category/priority/treatment indications of the voicemail to be recorded, and these indications are used to instruct the voicemail treatment and voicemail waiting indicator delivery. These indications are saved together with the corresponding voicemails in the voicemail system database.
  • Introduced voicemail system/application server initiated call to deliver the voicemail(s): if a voicemail treatment indication specifies that to make a call and deliver the voicemail to the recipient via call, the voicemail system or appropriate application server initiates a call to the recipient when the called device is free and deliver the voicemail via call. Here are two example cases:

i.     Voicemail system initiates the call. When a new voice mail is received and If the voicemail system is capable of initiating calls, it checks the recipient’s status (e.g. via presence server) and initiates a call to the recipient’s’ device when found free. When the call is answered, the recorded voicemail is delivered/played through the call. All voicemail handling features of the current existing voicemail listening (via phone) can be applied.

ii.     Application server initiates the call. If the voicemail system is not capable of making calls, an application server can be placed in between the voicemail system and user device. On receiving a new voicemail, the voicemail system delivers a voicemail waiting indicator through the application server to the user using existing method. On receiving such an indicator, the application server then checks the recipient’s status (e.g. via presence server) and initiates respectively a call to the recipient’s’ device and a call to the voicemail system when the recipient’s device is found free. When the call is answered, the two calls are bridged and the recorded voicemail is delivered/played through the call to the recipient. All voicemail handling features of the current existing voicemail listening (via phone) can be applied.

Optionally, an IVR/announcement server can be connected to the voicemail recipient before the call is connected to the voicemail system to prompt and allow the recipient to control this voicemail system/application server initiated call on how to handle the call and the corresponding voicemail. Also optionally, the voicemail system/application server can provide user preference configuration capability on how to initial the voicemail system/application server initiated call and the corresponding voicemail.

  • Introduced voicemail-caller-callee conferencing capability: when a voicemail is listened by the recipient via any type of calls described in above texts or traditional dial-in method, the voicemail system (if capable) or application server can initiate a conference call to the original voicemail sender to let the three party discuss the voicemail context lively.
  • Introduced voicemail aggregation/association: when a recipient listened a voicemail and calls back to the voicemail sender and is directed to the sender’s voicemail system, the replying voicemail and the original voicemail can be tagged and associated/aggregated via these tags. When playing back the voicemail by either party, the associated voicemail records can also be accessed for reference if needed.

3. Architectural diagram of the enhanced voicemail system/services

enhanced vms

“Select-to-visit” – a telephone IVR system base web page delivery and presentation capability

Filed under: Uncategorized — conningtech @ 8:45 pm

 

1.      Background information

“click-to-call” is a web capability that allows the web page viewer to make a real-time call to the targeted recipient while surfing the web page. The calling device can be a software phone client on the same computer or it can be any common independent phone devices (e.g. telephone, cellphone etc.) with its telephone number associated with the “click-to-call” configuration. When the “click-to-call” link/button in the web page is clicked by the viewer, a call is made between the viewer’s designated phone device to the targeted recipient and then the two parties can proceed with real-time call session when call is established. This is a great feature that integrates the information-rich web pages with the real-time on-demand capability of phone services, and is very useful in customer service type of applications.

 

In the traditional telephone based customer service (e.g. call center) use cases, the typical scenario is like:

  1. Customer calls the customer service number (e.g. a 1-800 number)
  2. The call is initially answered by the interactive voice response (IVR) system and the calling customer is prompted to follow and menu and response with appropriate selection so that the system can direct the call to appropriate agent and/or automatic handling logic.
  3. When the customer service call is initially established, a lot of customer service IVR introductive announcement has statement like “Welcome to xxx customer service, you can also visit our web page at www.xxx.com. For sales, please press or say ‘one’, for order status, please press or say ‘two’,……”
  4. In response to this “welcome” menu, if a customer want to visit the company’s web site, he/she needs to open the web browser and type in the company’s web link as announced and then start visit the web page. 

2.      Description of “Select-to-visit”

The “Select-to-visit” capability described here is to introduce the following capabilities into the telephone IVR system based applications that allows the web page be automatically opened in the customer’s designated device (e.g. computer, smartphone etc.) when the customer select the “visit company web” option in the IVR menu during the customer service call session.

  1. Customer calls the customer service number (e.g. a 1-800 number)
  2. The call is initially answered by the interactive voice response (IVR) system and the calling customer is announced the “welcome” menu like “Welcome to xxx customer service, to visit our web page at www.xxx.com, please press or say ‘nine’, for sales, please press or say ‘one’, for order status, please press or say ‘two’,……”
  3. If the customer press or say “nine”, the IVR system then trigger a web proxy server to issue a web request to acquire the company’s web page and redirect the corresponding reply to the designated calling customer web capable device (such as computer or smartphone that makes the customer service call).
  4. On receiving such web page reply, the client/agent in the customer device opens the customer preferred web browser automatically and displays the received page contents.
  5. The customer designated web page receiving device can be determined by either configuration in the customer’s account or customer device capability detection mechanism provided by the network.

Customer service/call center application is only one typical usage example of this “select-to-visit” capability. This capability can definitely be used in any other telephone IVR and web integration applications.

 

Wireless Signal Level Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:40 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more and more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere by a lot of means using his/her mobile devices.  A lot of these communication activities, however, will rely on certain wireless signal strength and traffic channel quality of service (QoS) levels, such as available average and top/bottom speed, retransmission rate, error rate and so on.

 

The wireless signal level based mobile device capability control provides a method that allows to control the communication capabilities of a mobile device based on the real-time wireless signal strength and traffic channel QoS  measurements and the user’s preference configuration. In brief, a functional module resides in the mobile device keeps monitoring the real-time wireless signal strength and the traffic channel QoS levels, and check them against the owner’s preference configurations and controls (e.g. enable, disable and any other possible forms of control) the use of the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) so that a specific communication capability (e.g. video calls) can only be placed when a certain wireless signal strength and certain QoS levels can be achieved at the use time. Such controls can be turned on or off by owners on their wills.

 

In addition to the real-time QoS measurement by the mobile device itself, QoS measurement can also be done by any existing or new network elements, and in this case, network measured QoS values can be delivered to the mobile device to help with the communication capability control decision making.

 

When user launches a function/capability/application that will need certain wireless signal strength and/or traffic channel QoS guarantees, a prompt can be raised to alter user for allow/disallow the function/capability/application.

 

Battery Level Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:37 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more and more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere by a lot of means using his/her mobile devices.  A lot of these activities, however, will require intensive usage of battery power. With the main purpose being for communications, especially for emergency voice calls for example, the mobile device is often the essential tool for a user to keep the basic and critical contact with others and therefore a user will most likely want or prefer to maintain some minimum battery power level to sustain this basic and critical need.

 

The battery level based intelligent mobile device capability control provides a method that allows to control the functional and communication capabilities of a mobile device based on the real-time battery level measurement and the user’s preference configuration. In brief, a functional module resides in the mobile device keeps monitoring the real-time battery level and check it against with the owner’s preference configurations and controls (e.g. enable, disable and any other possible forms of control) the use of the functional capabilities of the mobile device (such as static or video camera functions, recording functions, OTT Applications and so on) and the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) so that a given remaining batter power level can be reserved and limited only to the allowed functions/capabilities/applications corresponding to the battery level specified in the owner’s preference configurations. Such controls can be turned on or off by owners on their wills.

 

In addition to the real-time battery power level monitoring, estimated power consumption of a certain application (e.g. a video call etc.) can be calculated based on the wireless signal strength, screen brightness, network quality of service (speed, error/retransmission rates etc.) and so on. Control decision can then be made more intelligently by combining the remaining battery power level and estimated power requirement etc.

 

When user launches a function/capability/application that will need significant battery power, a prompt can be raised to alter user for allow/disallow the function/capability/application.

 

Location Based Intelligent Mobile Device Capability/Function Control

Filed under: Uncategorized — conningtech @ 8:32 pm

With the integration of more and more capabilities (such as static or video camera functions, recording functions and so on) into mobile devices, and with more and more varieties of services (voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) provided to the mobile devices, it is more convenient and flexible for a user to do activities of his/her interest at anytime and anywhere. This at the meantime imposes significant challenges to both the user him/her-self and the location owners when any of those activities are restricted by any means such as privacy, confidentiality, or any other forms of governmental or private restrictions at a specific location. To a user, he/she may involuntarily violate the laws or rules while doing disallowed activities in a specific location. To the location owners, such as government facilities with high confidentiality rulings, privacy and confidentiality protection becomes more and more vulnerable.

 

The location based mobile device capability control is a method that allows to control the functional and communication capabilities of a mobile device based on location. In brief, when a mobile device is entering a location (positioned by any types of Cellular positioning technologies, and/or GPS etc.), the functional capabilities of the mobile device (such as static or video camera functions, recording functions, OTT Applications and so on) and the mobile communication capabilities (such as voice call, video call, SMS, file/picture sharing, webRTC, chat, various OTT applications etc.) will be controlled (e.g. disabled or enabled or any other forms of controls) by an appropriate functional module resides in the mobile device either automatically or manually based on 1) user’s preference configuration and/or 2) suggestive or mandatory lawful/policy requirements of a specific location. When control decision is made based on user’s preference, all controlling calculations and logics are done in the mobile device. When control decision is made based on the lawful/policy requirements of a specific location or based on this information in conjunction with user’s preference, the location based lawful/policy requirements will be delivered to the mobile device from a server when the mobile device is entering a specific location to help making the control decision. The holding place of the relevant lawful/policy requirements can be a location owner owned server that is connected to the network and accessible by the mobile device and/or the network, or it can be a specific network server element that provide the location based lawful/policy requirements hosting services.

 

When a control decision is made and applied, the functional and communication capabilities of a mobile device will be limited or restricted according to user’s preference or location owner’s lawful/policy requirements.

A notes on HSS schema

Filed under: Uncategorized — conningtech @ 7:47 pm

HSS Schema Notes….

SIM, USIM, CSIM and ISIM Overview

Filed under: Uncategorized — conningtech @ 7:30 pm

An overview on wireless SIM, USIM, CSIM and ISIM……

October 12, 2010

3GPP VCC Call Control Procedures

Filed under: Uncategorized — conningtech @ 1:41 pm

1. Call origination from the IM CN subsystem

2. Call origination from CS domain

3. Terminating call directed to IM CN subsystem

4. Terminating call directed to CS

5. Terminating call coming from CS domain (using CAMEL)

6. Terminating call coming in through CS domain and delivered through the CS domain (1)

7. Terminating call coming in through CS domain and delivered through the CS domain (2)

8. CS domain to IM CN subsystem call transfer

9. IM CN subsystem to CS domain call transfer

October 11, 2010

UMTS to GSM Handover Procedures

Filed under: Uncategorized — conningtech @ 12:59 pm

1. Basic handover procedure requiring a circuit connection between 3G MSC-A and MSC-B (UMTS to GSM)
Basic handover procedure requiring a circuit connection between 3G MSC-A and MSC-B (UMTS to GSM)

2. Basic handover procedure not requiring the establishment of a circuit connection between 3G MSC-A and MSC-B (UMTS to GSM)
Basic handover procedure not requiring the establishment of a circuit connection between 3G MSC-A and MSC-B (UMTS to GSM)

3. Subsequent Handover from 3G MSC-B back to MSC-A (UMTS to GSM)
Subsequent Handover from 3G MSC-B back to MSC-A (UMTS to GSM)

4. Subsequent Handover from 3G MSC-B to MSC-B’ (UMTS to GSM)
Subsequent Handover from 3G MSC-B to MSC-B’ (UMTS to GSM)

5. Subsequent Handover from 3G MSC-B back to MSC-A without circuit connections (UMTS to GSM)
Subsequent Handover from 3G MSC-B back to MSC-A without circuit connections (UMTS to GSM)

6. Subsequent Handover from 3G MSC-B to MSC-B’ without circuit connections (UMTS to GSM)
Subsequent Handover from 3G MSC-B to MSC-B’ without circuit connections (UMTS to GSM)

7. Circuit-switched call establishment after a Basic UMTS to GSM Handover without circuit connection (UMTS to GSM)
Circuit-switched call establishment after a Basic UMTS tp GSM Handover without circuit connection (UMTS to GSM)

October 8, 2010

GSM to UMTS Handover Procedures

Filed under: Uncategorized — conningtech @ 12:52 pm

1. Basic handover procedure requiring a circuit connection between MSC-A and 3G MSC-B (GSM to UMTS)

Basic handover procedure requiring a circuit connection between MSC-A and 3G MSC-B (GSM to UMTS)

2. Basic handover procedure not requiring the establishment of a circuit connection between MSC-A and 3G MSC-B (GSM to UMTS)
Basic handover procedure not requiring the establishment of a circuit connection between MSC-A and 3G MSC-B (GSM to UMTS)

3. Subsequent Handover from MSC-B back to 3G MSC-A (GSM to UMTS)
Subsequent Handover from MSC-B back to 3G MSC-A (GSM to UMTS)

4. Subsequent Handover from MSC-B to 3G MSC-B’ (GSM to UMTS)
Subsequent Handover from MSC-B to 3G MSC-B’ (GSM to UMTS)

5. Subsequent Handover from MSC-B back to 3G MSC-A without circuit connections (GSM to UMTS)
Subsequent Handover from MSC-B back to 3G MSC-A without circuit connections (GSM to UMTS)

6. Subsequent Handover from MSC-B to 3G MSC-B’ without circuit connections (GSM to UMTS)
Subsequent Handover from MSC-B to 3G MSC-B’ without circuit connections (GSM to UMTS)

7. Circuit-switched call establishment after a Basic GSM to UMTS Handover without circuit connection (GSM to UMTS)
Circuit-switched call establishment after a Basic GSM to UMTS Handover without circuit connection (GSM to UMTS)

October 7, 2010

UMTS Handover Procedures

Filed under: Uncategorized — conningtech @ 12:57 pm

1. Basic handover procedure requiring a circuit connection between 3G MSC-A and 3G MSC-B
Basic handover procedure requiring a circuit connection between 3G MSC-A and 3G MSC-B

2. Basic handover procedure not requiring the establishment of a circuit connection between 3G MSC-A and 3G MSC-B
Basic handover procedure not requiring a circuit connection between 3G MSC-A and 3G MSC-B

3. Subsequent Handover from 3G MSC-B back to 3G MSC-A
Subsequent Handover from 3G MSC-B back to 3G MSC-A

4. Subsequent Handover from 3G MSC-B to 3G MSC-B’
Subsequent Handover from 3G MSC-B to 3G MSC-B’

5. Subsequent Handover from 3G MSC-B back to 3G MSC-A without circuit connections
Subsequent Handover from 3G MSC-B back to 3G MSC-A without circuit connections

6. Subsequent Handover from 3G MSC-B to 3G MSC-B’ without circuit connections
Subsequent Handover from 3G MSC-B to 3G MSC-B’ without circuit connections

7. Circuit-switched call establishment after a Basic UMTS to UMTS Handover without circuit connection
Subsequent Handover from 3G MSC-B to 3G MSC-B’ without circuit connections

October 6, 2010

GSM Handover Procedures

Filed under: Uncategorized — conningtech @ 9:47 pm

1. Basic handover procedure requiring a circuit connection between MSC-A and MSC-B
Basic handover procedure requiring a circuit connection between MSC-A and MSC-B

2. Basic handover procedure not requiring the establishment of a circuit connection between MSC-A and MSC-B
Basic handover procedure not requiring a circuit connection between MSC-A and MSC-B

3. Subsequent Handover from MSC-B back to MSC-A
Subsequent Handover from MSC-B back to MSC-A

4. Subsequent Handover from MSC-B to MSC-B’
Subsequent Handover from MSC-B to MSC-B’

5. Subsequent Handover from MSC-B back to MSC-A without circuit connections
Subsequent Handover from MSC-B back to MSC-A without circuit connections

6. Subsequent Handover from MSC-B to MSC-B’ without circuit connections
Subsequent Handover from MSC-B to MSC-B’ without circuit connections

7. Circuit-switched call establishment after a Basic GSM to GSM Handover without circuit connection
Subsequent Handover from 3G MSC-B to 3G MSC-B’ without circuit connections

October 5, 2010

Voice Call Continuity: 3GPP v.s. 3GPP2 — Registration

Filed under: Uncategorized — conningtech @ 9:12 pm

1. Background

For supporting VCC acrossing the traditional circult domain and new IP packet domain, a VCC UE needs to perform its traditional circuit domain registration as usural and an additional IP packet domain IMS registration.

2. 3GPP VCC Registration

3. 3GPP2 VCC Registration

Next Page »

Blog at WordPress.com.