This document proposes an information centric networking (ICN) approach for contextualized edge services. It discusses objectives like scalability, availability, and interoperability. It presents a service centric edge cloud platform with key components like an ICN service platform, orchestrator, and APIs. The platform supports open interfaces, context-aware and personalized services, and rapid service composition through network function virtualization. It describes aspects like context management, service composition methodology involving abstraction, composition and implementation phases, and functional service composition using a service-logic graph. Resource allocation and optimization problems in mapping services to infrastructure are also covered.

1. An Information Centric
Networking Approach Towards
Contextualized Edge Service
Peyman TalebiFard, Ravishankar Ravindran,
Asit Charkraborti, Jianli Pan, Anu Mercian,
Guoqiang Wang and Victor C.M. Leung

2. Outline
• Introduction
• Objectives and Motivations
• Service Centric Edge Cloud Platform
• Service Orchestration at the Edge Cloud
• Conclusion

3. Objectives and Motivations
• Scalability
• Availability
• Interoperability,
• Portable - Re-use - Decouple
• Context-aware and personalized
• Rapid service composition through NFV
• Improved operational efficiency
• Reduced CAPEX
• Standardized and open interfaces and APIs
• Performance monitoring of virtualized resources and the
infrastructure
• Resilience to network failures

4. Context-aware Service Composition
– Context as a Service by leveraging
• Processing
• Network
• Storage
– Context providers and context consumers

5. Types of Contextual Information

6. Service Centric Edge Cloud Framework
• Aimed for ICN-based applications such as conferencing
or IoT applications
• Leverage name based content dissemination, in-
network caching, receiver-oriented interest and data
multicasting, content level integrity, and privacy.
• Support open-APIs
• Adapt to user dynamism through adaptation to
changes of context,
• Capable of dynamic functional composition and enable
different ICN protocols and related services for future
deployments and experimentation.

8. Functional Components of the
Platform
• ICN Service Platform
• ICN Service Orchestrator
• ICN Service API

10. ICN Service Platform
• ISRs: implement the ICN forwarding plane.
• Virtualized services
• The platform specific service function
– ICN Service Access Point (ICN-SAP) per ISR
– ICN Service Profile Manager (ICN-SPM).
– ICN Service Access Layer (ICN-SAL) which resides
in the User Entity (UE).

12. ICN Service Orchestrator
• Interfaces with the ICN service owners (operator or
third party) to program the ICN service platform’s
resources through the ICN S-UNI.
• Invokes relevant ICN service controller and ICN network
controller functions to meet service objectives.
• The S-UNI allows service owners to express service
requirements during provisioning and request dynamic
changes to compute/storage/bandwidth resources to
adapt to service load conditions.
• Converts service requirements to compute, storage,
service connectivity, and bandwidth requirements to
meet service objectives.

14. ICN Service API
• Interfacing with external entities such as the
user and the ASPs for service access and
management
• Interfacing internally to promote inter-
operability.

15. SAL-SAP Interaction
• Service discovery
• Service request management
– For example as a result of context change.
• Service publish

16. Context Management
• Context sensing and collection: collecting the required
contextual information from different context sources
such as social communities, devices, network, and other
sensors.
• Context processing: is the inference of a situation from
raw data that are collected from different entities.
– Requires reasoning
• Inter-domain context handling and aggregation
– managing and aggregating the context information collected from various
sources and representing that in an easy to use and understand to be
shared with other entities.

17. Service Resource Distribution to a
Particular Service Interest
• Best Case
All services that a customer requires is available at the localized service pool.
• Worst Case
None of the requested services are not available at the local service pool. Each
requested service resource has to be obtained from distinct locations/domains
• Average Case
There are some service resources available at the local service resource pool, and
the rest of the service resources are located at one or more location

18. Service Composition Methodology
• Abstraction and Identification Phase
• Composition and Specification Phase
• Implementation and Realization Phase

19. Abstraction &
Integration
(XML)
Composition
(XML / WSDL)
Implementation
NDL: Network Description Language
RDF: Resource Description Framework
VNE: Virtual Network Embedding
ISR: ICN Service Router
VIMA: Virtual Infrastructure Management AgentLogical links for composition
Mapping
Virtual / Physical Infrastructure Overlay
Virtual Network Embedding (VNE) (Stage 3)
NDL / RDF
S1
S3
S4
S5
S6
S2
S8S7
AS
ISR1
ISR2
ISR3
Functional Abstraction of service (Stage 1)
Composition (Stage 2)
Objective
Service
S1 S2
S3
S4 S5
VIMA

20. <Services>
<inputs>
<outputs>
<Description>
…
<ServiceRequest>
<Context>
<Abstract Service Definition . XML>
<request.XML>
CLM or Look up
Solve VNE
Composition
Optimization
Processing
S2
S3
S4S5
S1 <New Service>
Service Request Management

21. Service-Logic Graph
• Presents an internal relationship between individual
services after decomposition; it shows the order of
service implementations, on the service name basis
• The graph is created based on pre-defined policies
– Since mobility requires service to be context adaptive, in-
network/transport/gateway services are appended to the consumer’s
major request, with dynamically configuration to adapt contextual
updates.
– A general policy for creating context-aware service logic is that in-
network services follow the major service requests from consumer
end.
• The service logic could be series or parallel or a mix of
series and parallel.

22. Name: serviceName
Type: service
Selector:
Interest PDU
Name: serviceName
Type: service
SIDx
Data PDU
ASPx
Content Item
Repository
…
Any Object with unique Identifier

23. VNE Phase
• Goal: Finding the best set of nodes and links
for running a service
• Minimize Cost function:
– F( bw , resource (cpu) )
– Link capacity constraints
– Compute resource constraint
– SLA requirements

24. Virtual Network Embedding (VNE)
VNRi = ( Ni , Li )
Demand function: demi : ( Ni ᴜ Li )  R
VNR1 = (N1 , L1)
VNR2 = (N2 , L2)
VNR3 = (N3 , L3)
S3 S3
S3
S2 S2
S1
S1
S1
ISR 1 ISR 3
ISR 2
VNRVNR
VNR
VNR : Virtual Network Request for service I
Ni : Set of virtual nodes
Li : Set of virtual links
Virtual Network Embedding

25. Conf.
Service
Conf.
Service
Conf.
Service
L3/L2
ISR-1
Internet
ICN Network Based
Conferencing Service
ICN Service Orchestrator
ISR-2
ICN A-UNI
ICN A-UNI
ICN S-UNI

26. Summary and Conclusion
• Context-aware service personalization.
• ICN-based Service centric framework.
• Service composition.
• ICN based platform as the enabler of a
semantic based intelligent networking of
information.

27. Questions & Comments

28. Service Layer Protocols ICN (CCN/NDN/MobilityFirst/NetInf etc.) SERVAL OpenADN
Naming (Cleanslate) Flexible (Flat, Hierarchical) (Incremental*) Flat Service ID (Incremental*)Application tag/Application Level
Switching
Name Resolution Coupled/de-coupled. Caching/Multicasting Online Resolution. No Caching
Consideration
Online Resolution. No Caching Consideration
Heterogenous
(Anycast, Routing, L2 )
Transport Agnostic, highly adaptable (Ad
hoc) (inherent features)
Adaptation at SERVAL level Adaptation at OpenADN Level (SDN) - IP Based.
Application API Get ()/Put()/Interest/Data (Receiver
Oriented)
Session based (TCP/UDP) Session based (TCP/UDP)
Security Content Level Session Level (Segmented) Session Level (Segmented)
Context/Service
Orchestration
Context-centric/Service
Composability/Natural Extension
No specific Consideration, but Application Meta-tags
Mobility Best-effort/Late binding (control plane) Handles Service level mobility (*not
content/host.device)
(No consideration) IP-Based

29. SAL
SAP
(Context management, Semantic Engine)
ICN
Service query (interest)
Discover entities
Return the URI of the entities
Request the information of the entities
Return the requested information
Collect data for service instantiation
Return the results
Iteration 1 of Class Composition
Apply service logic to the results
Response the results
Analysis
Publish the new service

30. App -1
Layer -3/Layer -2
ICN
Service Access Layer
Content
Context Sensing
Service
Discovery
Service Publish
Service Request
Management
Mobility
Location
Social
Device
App -2
App -N
Context Mgmt.
ICN APP -SAL
API
Home Router
Smart TV
Smart Phone
ICN Service Platform
Layer -3/Layer -2
Service Resource
Management
Service Request
Management
Service
Monitoring
Service Context
processing
Service Publish
ICN SAP -
Service API
Service -1
Service -2
…
Service -N
Service Access Point
UNI -API ICN Service Platform
L3/L2
…
ICN Service
Gateway
ICN
Service -1
ICN
Service -2
Device Scope
ICN Service Gateway

31. Service Context management
• Service Context Management module in the SAL:
• Interacts with the SAL modules as well as the
underlying infrastructure and access network.
• i.e Interaction with the service controller may not be sufficient
• Example: Context change may be triggered from service controller
• Abstracts the information and interaction with the
device hardware as well and the access network
technology to detect location, mobility and
topological changes

32. Context Sensing Module
• As part of the SAL context Sensing Module is in charge of triggering
on-the-fly functional composition based on the changes in the
context from the end-user device or based on the user behavior.
– The triggered action is interpreted in the SAP.
• This phase is responsible for interpretation and discovery of
functions that match the context of already instantiated service.
• Context sensing module can operate in two modes of operation.
– It can be queried to provide the structured context data format for
composing a new service.
– It can trigger actions based on the critical level of the action as it
pertains to the already running service.

33. Provisioning and Monitoring
• Provisioning should be done to dynamically
control the allocation and migration of IT
resource pool, Network, Compute, Storage.
• Service / Application health monitoring

34. Workflow Languages
• BPEL as a common example
• BPEL is an XML based language for process
oriented service composition
• In BPEL, processes are composed
• Message exchange among partners are based
on WSDL interface.

35. Workflow Languages
• Defining a process involves:
– Creation of a .bpel source file
– Process interface description based on WSDL
– XML optional descriptor of partner services

36. Distance based Similarity for Service
Selection
•Composition specification
can result in different
compositions depending on
the context
•Implicit specifications
results in larger degree of
freedom
•Explicit descriptions makes
the selections more limited
S1 S2
In(S1) Out(S1) In(S2)
Measure of similarity:
Sim (out(S1), { In(Si) | Si in Set of Candidate Services})

37. Service Discovery and Matching (SAP)
• Function : Sim( x , y )
• Matching two objects semantically
•
Exact Plug-in Subsume disjoint
Z= Sim (x , y) 1 1/2 < z < 1 0< z < 1/2 0
Interpretation x ≡ y x plugin y X subsume y x ≠ y

38. Formation of Service Logic Graph
Abstraction &
Integration
Composition
(WSDL)
Translation ( BPEL)
S1 S2
In(S1) Out(S1) In(S2)

39. Service/Context Ontology
• Impact on composition of services
• Impact on naming and (context-aware) name
resolution in ICN.

40. Example: Emergency Dispatch Service
Emergency Dispatch
directionService findNearestPoI call
getLocation lookup

41. Example: Emergency Dispatch Service
• Step 1: Finding services that yield a
connectivity (i.e. valid causal links)
– A causal link l : (s_x, sim, s_y) is causal iff
Sim(s_x , s_y) > 0

42. Example: Emergency Dispatch Service
• For the case of call :
– Valid causal link would select any candidate with
the following input parameters:
• Context vector C:
URI sip: voipNum phoneNum
Connection movementSpeed Device Location Etc.
Input Parameters
Descriptions Cost, quality, capability, typeOfCall,
Transcoding
, Other Features…

43. Example: Emergency Dispatch Service
• A user with the following situation
• The selection match (normalized) weight
vector would be:
User ‘s
Situation
GPRS connection, WiFi enabled device, looking for a
hospital, patient with critical condition.
Connection Cost Device TypeOfCall dropCallRate
0.6 0 0.3 0.2 0.1
Highest priority Non-important
Attribute
Weight

44. Resource Allocation
• Discrete optimization
• Resources can also be service components
• Sometimes utilization of a service is desirable
(elastic utility -> maximize revenue)
• Utilize the semantics and model as a social
network of Service Routers
• Mining social value of information w.r.t targeted
users
• Monotone
• Submodular (diminishing return)

45. Resource Allocation
• Problem can be formulated in terms of
allocation of services running on distributed
elements.
• Among a set of ICN routers
• Where to instantiate a service for a maximized
profit.
– Intrinsic value
– Network value (influence on adjacent nodes)

46. Optimization Problem Considerations
• Determining the coefficients for each of the
SLA parameters in the utility function
– Based on Context information
– Based on a sensitivity analysis

47. CLM Example
• A user wants to contact the customer service
of business X and speak with language Y.
lookup call
bName
lang
num num

48. CLM Example
Service S1 (lookup) S2 (lookup) S3 (call) S4 (lookup)
Input bName(r3,c3) bName(r3,c3)
lang(r2,c2)
Num(r4,c4) name
Output Num(r4,c4) Num(r4,c4) Call(r6,c6) Num(r4,c4)
i/j 1 2 3 4 5 6
Row i Addr lang bName num url call
Col j Addr lang bName num url call

49. CLM Example
C1 C2 C3 C4 C5 C6
1
2 { (S2,1) }
3 { (S1,1) , (S2,1) , (S4,2/3) }
4 { (S3, 1) }
5
6
Input 2 & 3  6
Input 2 & 3  4 Input 4  6