Sunday, May 19, 2019

ASN.1 and Interledger


Interledger is an open protocol suite for the exchange of payments across different ledgers (banks, blockchains, crypto currencies, etc.). It is a standard way of bridging financial systems. Like Internet Protocol (IP), it routes “packets of money” across independent payments networks. The Interledger architecture consists of three types of nodes, a sender, a receiver, and a connector. As their names suggest, the sender initiates a payment request for the receiver, and the request is routed through various connectors.

The Interledger protocol suite is divided into layers of protocols each with different responsibilities. The Ledger protocols represent the existing money systems that Interledger connects to. The Interledger Protocol (ILP) is the core protocol of the entire suite. Its packets pass through all participants in the chain, from the sender, through the connectors, to the receiver. ILP is compatible with any type of currency and underlying ledger systems. The Transport layer protocols are used for end-to-end communication between senders and receivers. The protocols at the application layer communicate details outside of the minimum information that is needed to complete a payment.


The protocols used in the Transport and Interledger layers are specified in ASN.1, a standardized syntax notation to define message structures and encodings in a platform-independent way. Interledger messages are encoded according to the ASN.1 Octet Encoding Rules (OER). Using ASN.1 to define and encode protocol messages allows Interledger applications to interoperate irrespective of their choice of platform and programming language. OER encodings are simple, compact, and very easy to parse. ASN.1 tools - commercially licensed as well as open source - are available to assist with implementation.

Interledger uses advanced features of ASN.1 to make future upgrades of the protocols extremely easy to incorporate and fully backward compatible. For example, if Interledger adds another message type to BilateralTransferProtocolPacket (see the ASN.1 excerpt below), they will only need to define the message and add it to CallSet, without worrying about backward compatibility.
CALL ::= CLASS {
    &typeId UInt8 UNIQUE,
    &Type
} WITH SYNTAX {&typeId &Type}
CallSet CALL ::= {
    {1 Response} |
    {2 Error} |
    {3 Prepare} |
    {4 Fulfill} |
    {5 Reject} |
    {6 Message} |
    {7 Transfer} |
    {8 NewMessageType}
}
BilateralTransferProtocolPacket ::= SEQUENCE {
    -- One byte type ID
    type CALL.&typeId ({CallSet}),
    -- Used to associate requests and corresponding responses
    requestId UInt32,
    -- Length-prefixed main data
    data CALL.&Type ({CallSet}{@type})
}
NewMessageType ::= SEQUENCE {
            -- Add message fields here
}

The OSS ASN.1 Tools can be used to implement the Transport and Interledger layer protocols. The Interledger ASN.1 specification is passed to the ASN.1 compiler to generate programming language specific structures or classes. The compiler generated code along with the high performance OSS ASN.1 runtime libraries are used to create applications for  the sender, the receiver, and the connectors. ASN-1Step, a GUI based product, can be used to view, create, and modify Interledger messages.

The OSS ASN.1 Tools include a sample Interledger program which demonstrates how the implementer of Interledger Bilateral Transfer Protocol (BTP) can use the Tools to serialize and parse BTP messages. The sample simulates the communication between two BTP peers and implements two scenarios, a) a payment request is successfully processed, and b) a payment request is rejected because it’s expired.

Please visit OSS website to find more information about the OSS ASN.1 products, to download a trial, and/or to access the online documentation. If you have any questions about using the OSS ASN.1 products in Interledger applications, please contact info@oss.com.

Wednesday, February 20, 2019

What's New in 2019 - OSS ASN.1 and NAS Tools

2019 is going to be an exciting year for our customers. We will update our ASN.1 and NAS tools to support 3GPP LTE and 5G Releases 15. In addition to enhancing our existing tools with new value added features, we will also introduce new NAS/Java Tools for LTE and 5G as well as new S1/X2 ASN.1 APIs for C# and Java.

Following the success of our NAS/C, NAS/C++, and NAS-1Step products, we are releasing the first version of our NAS/Java Tools supporting LTE Release 14. Users will be able to serialize/parse NAS messages from/to Java objects. In addition, the Tools will provide direct conversion of NAS messages to XML or JSON format. In the second half of the year, the Tools will be upgraded to support LTE and 5G Release 15. OSS will also be updating the existing NAS/C, NAS/C++, NAS-1Step products to support LTE and 5G Release 15.

A new PrintNAS feature will be supported in our NAS/C and NAS/C++ Tools. This feature will enable users to extract the field name, field type (sequence, choice, integer, bit string, etc.), field value (for integers, booleans, strings, etc.), offset of the field within the encoded message, size in bits of the field within the encoded message, and a pointer to the parent of the field. This feature will be useful to those who are interested in knowing the encoding details of their NAS messages.

This year OSS is releasing our new S1/X2 ASN.1 APIs for Java and for C#. Both tools will initially support LTE Release 14. The next version of the tools will be augmented to support LTE Release 15. These APIs will significantly reduce your S1/X2 protocol implementation efforts and provide an easier and less error prone upgrade path to newer 3GPP Releases. In addition, OSS will be updating the existing S1/X2 and LPPa ASN.1 APIs for C to support LTE and 5G Release 15.

An ASN.1 Studio enhancement will automatically create several messages for an input ASN.1 specification. This feature is useful for customers who are testing, as it will automatically generate several different types of test messages for their specification.

ASN.1/C# Tools support for partial decoding will enable you to quickly decode preselected fields from incoming messages. The main advantage of using partial decoding is that, when looking for a particular component in a large message, you can directly receive the value of the component you are looking for without having to navigate through the large message structure. This feature will be useful in many application areas including Lawful Intercept, routers, protocol analyzers, and Self-Organizing Networks (SON).

3GPP is currently working on Release 16 which is expected to be finalized by the end of the year. This Release will include support for Multimedia Priority Service, Vehicle-to-everything (V2X) application layer services, 5G satellite access, Local Area Network support in 5G, wireless and wireline convergence for 5G, terminal positioning and location, communications in vertical domains and network automation and novel radio techniques, etc. The OSS ASN.1 Tools will support Release 16. New samples will be added and existing samples will be updated to demonstrate how Release 16 ASN.1 based protocols can be used with the OSS ASN.1 Tools.



3GPP Protocol Based Products
Availability
3GPP LTE
Release 14 Support
3GPP LTE
Release 15 Support
3GPP 5G Release 15 Support
NAS/C LTE
Now
Now
N/A
NAS/C 5G
N/A
N/A
2Q2019*
NAS/C++ LTE
Now
Now
N/A
NAS/C++ 5G
N/A
N/A
2Q2019*
NAS-1Step LTE
Now
Now
N/A
NAS-1Step 5G
N/A
N/A
2Q2019*
NAS/Java LTE
2Q2019
3Q2019
N/A
NAS/Java 5G
N/A
N/A
4Q2019
S1/X2 ASN.1 API for C
Now
2Q2019
N/A
LPPa API for C
Now
2Q2019
N/A
S1/X2 ASN.1 API for Java
2Q2019
4Q2019
N/A
S1/X2 ASN.1 API for C#
2Q2019
4Q2019
N/A

N/A - Not Applicable
* Early Release available



Thursday, January 24, 2019

ASN.1 and eUICC

Changing your Mobile Network Operator (MNO), even doing so temporarily while travelling internationally, required you to replace your SIM with a new one. In today’s world where everything can be done remotely using online services, it is unreasonable to require a user to go to a store to obtain a new SIM card or wait for days for one to be delivered.
The Embedded Universal Integrated Circuit Card (eUICC) is an embedded SIM card. It differs from an ordinary (replaceable) SIM card in that it’s built into mobile, M2M, and IoT devices and cannot be replaced. When such a device is produced it already contains a smart SIM card (eUICC), containing no information specific to an MNO or an individual user.
With eUICC, there is no need to manually install and replace MNO specific SIM cards. Preparing an eUICC for use is called provisioning and entails downloading a certain MNO specific file, called a profile, to the eUICC. The profile is a data structure specified in ASN.1 and encoded in ASN.1 DER (Distinguished Encoding Rules). Its format is specified in the eUICC Profile Package: Interoperable Format Technical Specification from the SIMAlliance. ASN.1, an international standard supporting features such as compact binary encodings, interoperability, and platform independence, is a perfect choice for the format of eUICC profile.
eUICC vendors can use OSS’ ASN-1Step to manually create eUICC profiles. They would receive provisioning information for a set of devices from a carrier, enter the information in the Value Editor of ASN-1Step, and encode to DER in order to create one or more eUICC profiles which can be transferred to the eUICC of target devices. Profiles can also be viewed or modified using ASN-1Step.



A Remote Provisioning System (RSP) allows for remote provisioning of the eUICC with a Mobile Network Operator (MNO) profile. The RSP also enables the secure, dynamic changing of profiles.
The OSS ASN.1 Tools can be used on the network elements of Remote Provisioning Systems to create and parse profiles. Various interfaces of the RSP nodes exchange profiles (encoded in ASN.1 DER), for example, the interface ES9+ between the SM-DP+ (Subscription Manager Data Preparation) and the LPD (Local Profile Download), and the interface ES11 between the LDS (Local Discovery Service) and the SM-DS (Subscription Manager Discovery Service). These interfaces can be implemented using the OSS ASN.1 Tools. The ASN.1 specification used by the RSPs is found in the GSMA RSP Technical Specification document. The specification is passed to the ASN.1 compiler to generate programming language specific structures or classes. The compiler generated code along with the high performance OSS ASN.1 runtime libraries are used to create applications for use on the RSP nodes to create and parse profiles.




Visit this link for more information about the OSS ASN.1 products and to download a trial. Online documentation for the ASN.1 products can be accessed here. If you have any questions about using the OSS ASN.1 products in eUICC applications, please contact info@oss.com.



Sunday, July 15, 2018

ASN.1 in eCall

eCall is a European Commission initiative (CEN TC278/WG15) intended to bring swift assistance to vehicles involved in a collision anywhere in the European Union. Effective April 2018, eCall is mandatory in all new cars sold within the EU.

The eCall system relies on an In-Vehicle System (IVS) consisting of an eCall application, Cellular Network Connectivity (GSM), a Global Positioning System (GPS), Vehicle Connectivity (CAN), and a GSM modem to transmit vehicle information to an emergency call center, e.g. Public Safety Answering Point (PSAP). In the event of a collision or emergency, via an eCall communication session, the IVS transmits to the PSAP a Minimum Set of Data (MSD) which contains vehicle information, for example, vehicle type, current location, previous locations, propulsion storage type, number of occupants, etc.

The European Standard, EN 15722, “Road Transport and Traffic Telematics”, defines MSD using ASN.1, an international standard used to define data structures and encodings. MSD is encoded in ASN.1 Unaligned Packed Encoding Rules (UPER). The reliability and robustness of ASN.1, and the availability of the limited data space for MSD made ASN.1 and UPER an ideal choice for the eCall standard.





OSS Nokalva, a global leader in ASN.1 technology, provides several ASN.1 Tools which can be used by eCall applications to encode an MSD and by PSAP applications to decode it. The feature-rich ASN.1 Tools, optimized for performance and size, support C, C++, Java, and C# programming languages and have been ported to more than 500 platforms, including embedded and custom platforms.

The MSD ASN.1 specification is compiled by the OSS ASN.1 compiler to generate programming language specific structures or classes. The application code for the eCall system fills these structures/classes, calls the OSS ASN.1 runtime codec to encode the MSD to UPER encoding, and sends it to PSAP via the GSM modem in the In-Vehicle System. The PSAP application calls the OSS ASN.1 decoder to decode the MSD in the structures/classes and uses the decoded values for display on the PSAP operator’s console and/or notifying other emergency services.

For more information about the OSS ASN.1 Tools visit. Online documentation for the Tools can be accessed here. If you have any questions about using the OSS ASN.1 Tools in eCall and PSAP applications, please contact info@oss.com.

Monday, December 11, 2017

ASN.1 in C-V2X Communications


Cellular Vehicle to Everything (C-V2X) communications, designed to improve road safety, achieve more efficient traffic flow, reduce environmental impacts, and provide new useful services to travelers, uses several ASN.1 based control plane signalling protocols - RRC, M2, and M3.
3GPP defines four types of C-V2X communications - vehicle to vehicle (V2V), vehicle to pedestrians (V2P), vehicle to roadside infrastructure (V2I), and vehicle to network (V2N).
V2V and V2P communications are based on broadcast capabilities between vehicles or between vehicles and pedestrians, and are designed  to avoid accidents by providing information about the location, velocity, and direction of vehicles.
V2I communication occurs between vehicles and roadside units (RSU) which may act as repeaters to extend the range of V2X messages. V2I also includes communication between vehicles and traffic control devices such as signs, markers, barricades, and signal devices which are used to inform, guide, and control traffic.
V2N communication, over 4G/5G networks, occurs between vehicles and servers (e.g. traffic operation servers) in order to provide a complete view of road events.
There are two modes of operation for C-V2X - direct communication, and network communication.  ASN.1 protocols are used in both of these modes of operation.
Direct communication mode uses the LTE PC5 interface based on  3GPP Proximity Services (ProSe). This mode is used for V2V, V2P, and V2I communications. ProSe supports three coverage scenarios, in-coverage, out-of-coverage, and partial coverage. In the in-coverage scenario, the network controls the resources used in ProSe communications. In the out-of-coverage mode, vehicles use pre-configured resources for sidelink communication with nearby vehicles. However, in the scenario of partial coverage, the vehicle out-of-coverage uses the preconfigured values, while the vehicle in-coverage gets its resources from the network.



The OSS ASN.1 Tools, development toolkits for ASN.1 based applications, can be used to develop C-V2X solutions.  A sample program included with the OSS ASN.1 Tools demonstrates how to implement C-V2X signaling using the partial coverage scenario. The sample demonstrates how an in-coverage vehicle, acting as synchronization reference for the transmitting (out-of-coverage) vehicle, receives SystemInformationBlockType21 (part of BCH-DL-SCH-Message) from the eNB, configures its sidelink, and transmits MasterInformationBlock-SL (part of SBCCH-SL-BCH-Message) message to the transmitting vehicle, which in turn modifies the received MasterInformationBlock-SL message and re-transmits it for C-V2X sidelink communication and discovery for other out-of-coverage vehicles. Using Sidelink discovery vehicles repeatedly broadcast short and fixed-size MasterInformationBlock-SL (SBCCH-SL-BCH-Message) messages that can be detected by nearby vehicles, so they can synchronize with each other to establish wireless connectivity.  The control plane messages in this exchange are based on ASN.1 RRC.
The other mode, mainly used for V2N communication, utilizes the LTE Uu air interface between UEs (vehicles) and eNBs. As an example of V2N mode, a vehicle sends a message via an eNB to an application server which, using Evolved Multimedia Broadcast Multicast Services (eMBMS) - a point-to-multipoint LTE interface for efficient delivery of broadcast and multicast service - in turn broadcasts the message to all nearby vehicles.. The control plane messages in this exchange are based on ASN.1 RRC, M2, and M3 protocols.



The OSS ASN.1 Tools are packaged with sample programs for 3GPP protocols such as RRC, M2, M3, and various other protocols.  These samples can be found under the “samples/standards” directory. To learn more about the ASN.1 Tools, please visit or contact us at info@oss.com.

Friday, August 4, 2017

Reduce Your Application's Footprint


The enormous increase in the use of resource constrained IoT devices, presents an ever increasing challenge to developers to keep the size of their application code within very tight memory limitations. The OSS Time Optimized Encoder/Decoder (TOED) can meet these challenging requirements. It’s not only a high performance encoder/decoder, but when used with specific options, it yields a very small footprint, e.g. 60 kilobytes for a LTE RRC UPER encoder/decoder.

In the latest release (summer 2017) of the OSS ASN.1 Tools, a new feature has been added to reduce the footprint even further. With the new versions of the OSS ASN.1 C (10.5) and ASN.1/C++ (6.5) Tools , you can further reduce the size of your application by controlling the inclusion of error strings in your application. When using the -toed option of the ASN.1/C or ASN.1/C++ compiler, you can define the C manifest constant OSS_REDUCED_ERROR_MSGS when compiling the code generated by the ASN.1 compiler to reduce the runtime error messages to only the error prefix for each error message instead of the complete message. In addition, by defining OSS_DEBUG=0, you can remove the error messages completely.  Since error details will no longer be provided, these options are best be used after you have completed debugging your application.  

The elimination of the array of error strings from your application can significantly reduce the application code size on resource-constrained platforms.  For example, a full error message such as the following:

D0081S: End of input reached before message was fully decoded; check field 'b' (type: INTEGER) of PDU #3 'C'.

would be reduced to the following:

D0081S.

when OSS_REDUCED_ERROR_MSGS is defined. No error message text would be generated at all when OSS_DEBUG=0 is defined.

To give you an example of how much additional footprint reduction you can achieve, our testing of the new feature revealed that the footprint of the application was reduced by 18 kilobytes on  Linux x86 when we C compiled the code generated by the ASN.1 compiler with -DOSS_REDUCED_ERROR_MSGS. Using -DOSSDEBUG=0 further reduced the application footprint by an additional 3-4 kilobytes on the same platform.  Please note that you may achieve different results on your platform, depending on the operating system, processor, and C compiler you use.

While this new feature could be useful to anyone working on embedded devices where memory is precious, we expect that  developers working with 3GPP LTE-M and NB-IoT technologies will find it extremely valuable when developing solutions for Cat-0, Cat-1, Cat-M1, and Cat-NB1 devices.

For more information about the OSS ASN.1/C, OSS ASN.1/C++ Tools, or about this new feature, please click here, or contact info@oss.com.