Flexible Protocol Stack Framework : Design, Validation and - - PowerPoint PPT Presentation

▶
flexible protocol stack framework design validation and
SMART_READER_LITE
LIVE PREVIEW

Flexible Protocol Stack Framework : Design, Validation and - - PowerPoint PPT Presentation

Aug 22, 2023 370 likes •606 views

O C U S T Flexible Protocol Stack Framework : Design, Validation and Performance Tim Farnham 1 , Thorsten Schler 2 SDR Forum Technical Conference November 2003 1 Toshiba Research Europe Ltd 2 Siemens AG Authors: Tim Farnham, Date:

slide-1
SLIDE 1

Date: 30/09/2003 Page: 1 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Flexible Protocol Stack Framework : Design, Validation and Performance

Tim Farnham1, Thorsten Schöler2

SDR Forum Technical Conference November 2003

1 Toshiba Research Europe Ltd 2 Siemens AG

slide-2
SLIDE 2

Date: 30/09/2003 Page: 2 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Contents

  • Introduction
  • Terminal architecture
  • Flexible protocol stack framework

– Design – Validation – Performance

  • Conclusions
slide-3
SLIDE 3

Date: 30/09/2003 Page: 3 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Reconfigurable protocol Reconfigurable protocol stack architecture stack architecture

Reconfigurable hardware Reconfigurable hardware

Digital signal processing hardware Custom hardware Highly-optimised software (system / kernel) Object-oriented software

Terminal architecture

ISO OSI level Implementation domain

Layer 7: Application Layer 5: Session Layer 6: Presentation Layer 3: Network Layer 4: Transport Layer 1: Physical Layer 2: Data Link Layer

slide-4
SLIDE 4

Date: 30/09/2003 Page: 4 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Ad Hoc Networks Reconfiguration Functions (MIMM, MNSM etc.) Middleware Network Link Physical Hardware

Network Centric Support for Reconfiguration

Application Hardware Reconfiguration Functions (CMM, RSMM etc.) Middleware Transport #1 Network #1 Link PHY Baseband Execution environment Flexible protocol stack Reconfigurable Terminal

Service Discovery Mode Selection Software Download

Cellular Networks Reconfiguration Functions (MIMM, MNSM etc.) Middleware Network Link Physical Hardware

CMM: Configuration Management Module RSMM: Resource System Management Module MIMM: Mode Identification and Mode Monitoring MNSM: Mode Negotiation and Switching Module

Hardware Abstraction Layer RF Transport #2 Network #2 Transport #n Network #n

slide-5
SLIDE 5

Date: 30/09/2003 Page: 5 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Requirements and Solution Features for Flexible Protocol Stacks

  • Platform Independence

– Multiple CPU / execution environment and language support

  • High reliability / availability

– Fallback states, etc. – Validation of Stack Configuration and Implementation

  • Secure operation

– Mechanisms to prevent unauthorised interception, manipulation

  • Multi-vendor sourcing

– Manufacturer, operator, service provider and third party – Open interfaces

  • Dynamic optimisation

– Depending on resource availability, execution environment and service requirements – Mechanisms for active protocol stack reconfiguration

  • Customisation and enhancement

– Mechanisms to allow incremental upgrading

slide-6
SLIDE 6

Date: 30/09/2003 Page: 6 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Contents

  • Introduction
  • Terminal architecture
  • Flexible protocol stack framework

– Design – Validation – Performance

  • Conclusions
slide-7
SLIDE 7

Date: 30/09/2003 Page: 7 Authors: Tim Farnham, Thorsten Schöler

S C O U T

State of the art in modular protocol stacks

Composable Composable protocol stacks protocol stacks (run time) (run time) Customisable protocol stacks Customisable protocol stacks (design time) (design time)

Layer α Layer β Layer γ

Library Framework

Terminal A Terminal B Generic Protocol Stack Terminal B specific SW Terminal A specific SW Terminal B Protocol Stack Terminal A Protocol Stack 1 1 1 1

X-Kernel – Composable (at compile time) framework with configurable virtual protocol layers OPtIMA – Java based, composable and (run-time) customisable framework with configurable active programming interfaces DIMMA – C++ based, customisable framework which is derived from X-kernel framework

slide-8
SLIDE 8

Date: 30/09/2003 Page: 8 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Protocol stack computation models

Process per protocol Process per protocol Process per message Process per message

Thread for layer α Thread for layer β Thread for layer γ Thread for message 1 Thread for message 2 Static code layer α Static code layer β Static code layer γ Message 1 Message 2 queue

slide-9
SLIDE 9

Date: 30/09/2003 Page: 9 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Proposed Flexible Protocol Stack Framework

INET IRL

GPI

DGSAP DGSAP DGSAP

GSAP

CMM

getBestMode measurePerformance resourceAllocation getInformation

MNSM MIMM SDM RSMM

addMode CM GSAP = Open Interfaces

attach/bind/connect

Middleware

QoS Manager Note : MIMM = Mode Identification and Monitoring Module (or Mode Identification and Monitoring), MNSM = Mode Negotiation and Switching Module (or Mode Switching Module), SDM = Software Download Module, RSMM = Resource System Management Module (or Resource Management System), GPI = Generic Protocol Interface, GSAP = Generic Service Access Point, CM-GSAP = Connection Management GSAP, CMM = Configuration Management Module, INET = Internet TCP/IP Stack, IRL = Intelligent Routing Layer.

slide-10
SLIDE 10

Date: 30/09/2003 Page: 10 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Framework Key Features

  • Generic Protocol Interface (GPI)

– Language and platform independent – Radio access technology independent

  • Generic Service Access Points (GSAPs)

– Dynamically bound and rebound – Secure interaction between layer instances – Extensible message data format – Execution environment neutral

  • Intelligent Routing Layer (IRL)

– Supporting dynamic mode selection

slide-11
SLIDE 11

Date: 30/09/2003 Page: 11 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Generic Protocol Stack Example

Packet Classification / Scheduling Alternative Mode Detection / Monitoring Encryption / decryption Link Adaptation Performance measurement Compression / decompression Association / registration Connection setup Packet fragmentation / reassembly Medium Access Control (MAC) / CRC Generation / Scrambling / whitening

Radio PHY

  • = GPI

= GSAP Key : = Generic component

Packet Classification / Scheduling Alternative Mode Detection / Monitoring Encryption / decryption Link Adaptation Performance measurement Compression / decompression Association / registration Connection setup Packet fragmentation / reassembly Medium Access Control (MAC) / CRC Generation / Scrambling / whitening

Radio PHY

  • = GPI

= GSAP Key : = Generic component

Packet Classification / Scheduling Alternative Mode Detection / Monitoring Encryption / decryption Link Adaptation Performance measurement Compression / decompression Association / registration Connection setup Packet fragmentation / reassembly Medium Access Control (MAC) /

Radio PHY

  • = Generic

Protocol Interface = Generic Service Access Point Key : = Generic component

slide-12
SLIDE 12

Date: 30/09/2003 Page: 12 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Reconfiguration Management Interactions

Intelligent Routing Layer (IRL)

Generic Protocol Interface

DGSAP DGSAP DGSAP Generic Service Access Point (GSAP) Best Modes Performance Allocate Resource Capabilities Mode attributes Connection Management GSAP attach/bind/connect Management interactions

  • Open interfaces

allow reconfiguration

  • f protocol stack to

exploit the capabilities of the platform execution environments and customisation and enhancement options within protocol software.

slide-13
SLIDE 13

Date: 30/09/2003 Page: 13 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Contents

  • Introduction
  • Terminal architecture
  • Flexible protocol stack framework

– Design – Validation – Performance

  • Conclusions
slide-14
SLIDE 14

Date: 30/09/2003 Page: 14 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Protocol stack validation process

Mobile terminal

Layers: DummyLid l6, Dummy l5, CRC l4, Fragment l3, Dummy l2, DummyBase l1 Channels: l6<->l5, l4<->l3, l3<->l2, l2<->l1 Param: l6: default l5: default l4: crc_size=16 l3: max_frag_size=1024 l2: default l1: mirror=true Layers: DummyLid l6, Dummy l5, CRC l4, Fragment l3, Dummy l2, DummyBase l1 Channels: l6<->l5, l4<->l3, l3<->l2, l2<->l1 Param: l6: default l5: default l4: crc_size=16 l3: max_frag_size=1024 l2: default l1: mirror=true

Syntax check Semantics check

  • Terminal-based validation

– On-line validation

  • Check of protocol stack configuration

– Syntax and semantics

– Run-time validation

  • In protected execution environment
  • Software probes in protocol stack

software

– Assertion-based

Configuration server Network simulation Simulated user HW simulation

  • Network-based validation

– Off-line validation

  • Virtual prototyping

– HW, SW, Network simulation – Simulation of actual stack implementation – Assertions for validation of software correctness

Mobile execution environment Layer 1 Layer 2 Layer 3 SW probes Framework

slide-15
SLIDE 15

Date: 30/09/2003 Page: 15 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Contents

  • Introduction
  • Terminal architecture
  • Flexible protocol stack framework

– Design – Validation – Performance

  • Conclusions
slide-16
SLIDE 16

Date: 30/09/2003 Page: 16 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Secure Asynchronous Messaging

Logical layer 1 Logical layer 2

Send(req) Lookup Q Post message to Q Semaphore Lock – on thread / Q data Lookup Q validate message Semaphore Lock – on thread / Q data Semaphore Lock – on Q Semaphore to signal data in Q Semaphore Lock – on Q Request

  • peration

Send(res ) Lookup Q Post message to Q validate message Semaphore Lock – on thread / Q data Semaphore Lock – on Q Semaphore to signal data in Q Semaphore Lock – on Q Semaphore Lock – on thread / Q data Response

  • peration

Retrieve message from Q Retrieve message from Q

  • Execution environments

provide protection between logical protocol layer instances

  • Interaction between

instances authorised to prevent rogue behaviour

  • Different steps to

accommodate different execution environments and computational models

slide-17
SLIDE 17

Date: 30/09/2003 Page: 17 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Benchmarking Platforms

Intel PXA 250 400MHz with Pocket PC 2002 PXA WinCE Intel PXA 250 400MHz with Linux 2.4.18 PXA Linux Intel StrongARM 200Mz with Enea OSE Delta RTOS SA OSE Intel StrongARM 200MHz with Linux 2.4.18 SA Linux 1GHz Intel P3 PC with Windows 2000 PC Windows 1GHz Intel P3 PC with Linux 2.5.54 PC Linux Type Name

  • Three hardware platforms and four different operating

systems

  • Java Virtual Machines also considered on Linux
  • perating and Windows systems
slide-18
SLIDE 18

Date: 30/09/2003 Page: 18 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Benchmark Results

1 10 100 1000 10000 Native (POSIX 1003.1b) Native (System V) Native (POSIX 1003.1b) Native (System V) Java Blackdown (POSIX) Native (OSE messaging) Linux Native (POSIX ) Linux Native (System V) WIN CE 3.0 Native Native (Windows) Java (J2SE HotSpot) Latency in microseconds No Context Switch 1step 3step 5step Java Blackdown (System V) SA Linux Java GCJ (GCC3.2 – System V) Java GCJ (GCC3.2 – POSIX) Java (J2SE HotSpot – System V) Java (J2SE HotSpot – POSIX) PC Linux PC Windows PXA 250 SA OSE

slide-19
SLIDE 19

Date: 30/09/2003 Page: 19 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Results Summary

  • Operating different logical layer instances in

separate execution environments is attractive to exploit heterogeneous execution environments

– Native threads and processes – JVM threads and processes

  • The overhead in performing context switching

must be considered when partitioning the protocol stack between execution environments

  • Thread context switching and asynchronous

messaging can actually be less computationally intensive than Java native calls using Java Native Interface (JNI)

slide-20
SLIDE 20

Date: 30/09/2003 Page: 20 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Results Summary - continued

  • Computationally intensive operations such as

CRC calculation within a JVM protocol module can present much higher latency than thread or process messaging and native processing

  • Memory requirements of Java implementation

considerably higher than native implementation

  • Performance variation across different platforms

and computational models considerable

– 1000 to 1 variation in benchmarks

  • Context switching can be avoided if a single

execution environment provides the necessary performance and security, but this will not generally be the case

slide-21
SLIDE 21

Date: 30/09/2003 Page: 21 Authors: Tim Farnham, Thorsten Schöler

S C O U T

Conclusions

  • Flexible protocol stack framework based on open

interfaces and generic service access points is an attractive approach

  • Different execution environments and

computational models are also attractive to provide best use of resources

  • Validation can be most efficiently performed in a

combined off-line, on-line and at run-time manner

  • Performance results indicate that secure

asynchronous messaging is a viable and lightweight solution for supporting the framework