1 Distributed Processing in telecom Ttm4125 lecture 2

2 Parallel processes and concurrency (fig. 2.1) ’ 3’ 4’ 1’’2’’ 3’’ 4’’ Signalling (control operations) Media flow (here circuit switched voice External interfaces I1 and I2: 2 types 2 instances of each type I1 I2

3 Processes and interfaces both have: Instances and types Instances of type ’subscriber/access controller’ Instances of type ’switch controller’ (controls teh switch fabric 4, 4’, 4’’) Instances of type ’B-number analysis’ (routing) I1: type UNI (user-netw. i/f) I2: type NNI (netw-netw. i/f) 2 subtypes inside 1 adm.domain vs between domains 2 1 3’ 1’’ 2’ 3 2’’ 3’’

4 Messages: asynchronous and concurrent Asynchronously (one-way) Concurrency –Independent timing B may start calling A, even though A has already started to call B Separate lifetimes of the processes Responsible for own recovery –Timer in process 2: in cases 2’ does not reply, 2 may kill itself, and release resources

5 Feature of telecom Concurrency Weak coupling Information hiding –Show messages, not internal implementation Weak synchronisation (time independece) Error recovery –E.g. Use timers to recover from dead other end

6 Messages and information hiding External messages (’between boxes’, e.g. over I1 and I2) –Message exchange is defined –Internal implementation hidden from outside Internal messages (’inside one box’ (server/switch) –Often proprietary: also the specification in terms of message exchange may be proprietary –Implementation hidden as in previous case

7 MSC: Message sequence chart (fig P3)

8 Relations to HS and SS diagrams (from ProgDesign) Fig. 2.1 contains some hardware information –The information about the physical boxes will typical blong to a HS diagram in ProgDesign Find-route and result can be implemented as procedure call with return value –This implementation information typically belongs to a SS diagram in ProgDesign Process Procedure callData 2’3’ (B-number analysis data)

9 Lifetimes of different processes Fig. 2.2(b) (page 3) shown a very short lifetime of the processes 3, 3’ and 3’’ because: –Each instance can be viewed as completely independent No state information shared between different messages sent to B-number analysis, hence: We can view them as different instances –It does not show the persistent B-number-data

10 Different levels of view Slide 1 (fig. 2.1 in lect.notes) shows not only abstract processes –But also (’deployment view’): where /which hardware instance (or type) each process in running on Such detailed hardware information may give useful information. (May be considered part of ’technonogy’ and/or ’engineering’ view) A more abstract view (pure computational view) –Show only all processes (no boxes/hardware) –The MSC diagram in fig.2.2(b) corresponds to this (if we remove the I1 and I2 information)

11 Computational view Alternative 1 SDL : –processes and messages + MSC –+ definition of signals (abstract/ logical) Here internal SDL behaviour may be added Alternative 2: (ODP: Computational objects) –Use CO: Computational Objects (’process’) –IDL (interface Definition Language) (def. Signals) –Collaboration diagrams or MSC CORBA/ Java RMI implements ODP: –often uses procedure calls, not asynchronous messages

12 Logical view of message sending Supported both in SDL and ODP From fig. 2.4: ODP supports: –Object types and subtypes, instances –Interface types, subtypes and instances –Operational interfaces: (for signalling/ control/ RPC) –Stream interfaces, with stream flow endpoints (SFEP) For media flow P1 P2 Logical Protocol Physical info transfer

13 ODP: Computational objects Operational i/f: –(receive message) offered interfaces –Send message (requested interface from other side) Not on figure, written in text Stream interface with source and sink Everything is typed, and types much match

14 Separation of service execution and switching (service), call and connection separation, –Note how they always follow same path and the same physical boxes in PSTN: (not separated) –Separated in UMTS IMS (SIP) and H.323 Separation of types of interfaces Operational interfaces (for the signalling) Stream innterfaces (for the media flows) –This support the separation Read also ch. 2.5 and 3.1!

15 Motivation (recap. from 1st lecture) 2.2: –GSM example (skipped for now the protocol arch. part) 2.3 Heterogenety and complexity Different actors (business roles): more in ch. 4! Different machines and types of terminals Different access networks Want common modelling tools that can sometimes hide these differences

16 Transparencies Help hiding some details that are irrelevant in this particular view Access transprancy –NB Nothing to do with access network! NB –An abstract definition of message interfaces IDL (Interface Definition Language) –Hides details such as: |processes running on the same or different machines

17 More transparencies Location/ migration transparencies: –Application (processes / objects) may move between machines also at runtime (without me noticing) –Hides the information about the mapping from CO to machine/HW Replication transparency Persistence transparency –Hides life cycle management –Hides activation/deactivation

18 Ch.4 Domains / enterprise view Domain information: E.g. The 2 leftmost boxes in fig. 2.1 belong to Telenor, and the 3rd box to Tele2 –Such information belongs to ’enterprise’ view (Often a separate GW (gateway) will be needed in this case, and 2 subtypes of I2 will be needed –See e.g. Chap. 4.4 for more info on domain interactions –In this case the technology is the same, so we need no in-line interceptor Ch. 4 is mostly ’computational independent’ –Ref. OMG/ MDA : CIM Comp. Independent Model –Requirements and objectives from a business perspective

19 Gateway (split interceptor) If I2-int and I2-ext is the same: –the data in 3’ and 3* and in 2’ and 2* may be different, ( and e.g. set CLI to unknown) –Additional behaviour may be needed in the GW An ’other operator controller’ somewhat similar to the ’subscriber controller’, to handle the domain boarder I2-int and I2-ext may also be more different * 3* 4* 1’’2’’ 3’’ 4’’ 2’ 3’ 4’ i1:I1 i2:I2-int i9:I2-ext I2’:I2-int i5:I1

20 Ch.5: Information model (IM) The basics here are assumed known –from UML-course, like ’software –But check the graphical notation used here in fig. 5.2 Info models are often computational independent Ex: Info model for voting (election). A relationship exist between voter and (0:1) vote, but this relation is abstract, and shall not correspond a an actual relation in a database. (After all the voting procedure shall be secret!) May also be information about how the computation is executed –E.g. : processes 2’, 3’ and 4’ run on the same hardware can be expressed in an IM

21 Enterprise model and info model Often we use IM to express the enterprise model, e.g. for GSM (ch. 9) –User has subscription relation via SIM card with home network –Home network has roaming agreement with visiting networks –No billing relation between user and visited network

22 Names and naming domains Continue from GW / split interceptor slide: –In case of international gateway, naming conversion will be handled here at the name domain boarder Naming (and routing) are extremely important parts of telecom systems! Administrative domains and domain borders are also important Administrative domains can be of two types: –Within one company –Between separate companies (reg. in Brønnøysind) Companies in the same business roles (2 GSM operators) Companies in different business roles –Video-provider vs network/connectivity provider, consumer vs retailer

23 Names and naming domains –Eks. 1 (telephony) (internal at NTNU switchboard) (Norwegian variant of ’same’) (international) Here prefixes are used when ’jumping out’ of a domain –Eks. 2 (postal adresses) A-263, Elektro (internal at NTNU) A-263, O.S.B Pl 2A, 7000 Trondheim Here postfixes are used when ’jumping out’

24 Information hiding Some internal names may not be visible outside –Ex.1: may not be allowed for ’direct dialling in’), so may be illegal Or need more serious address translation –Ex.2: (Internet) NAT The PBX or the FW/NAT-box will provide the necessary functions for this

25 All names are ’local’ By this I mean: All names are valid in one (the ’local’) naming domain –(which may be small or big) –Domains may have names as well (e.g. dot notation) The same local name (like or lillk) may occur in many naming domains –Each domain determines locally the ’thing’ that is named by this name in this given context (i.e. locally) –This may cause some problem for mobility, if proper care is not taken!

26 Naming domain / context / validity of a name (1) may name (2) as (3) may name (2) as It may be that (3) cannot name (’see’) (1) (1) may name 3 as prefix 0, (4) may have local name Blue: international split ic Green: PBX Split ic Norway UiO NTNU *(2) name91486 *(1) name91111 *(3) name *(4) name91486 *(5) name 09000

27 Info model and enterprise models Ttm 4125 Lecture 3 (more to come soon…)

28 An InfoModel for enterprise view See fig. 4.3 Broker *Retailer *Consumer *Clearinghouse Connectivity provider *3rd party service prov. Other relations may occur between these roles –Ex.IP: An ISP often bills the consumer directly for his connectivity, and many service providers exist without relations to a broker. Compare postal orders: buy goods and shipping from one place, –Buy video from retailer, who orders the transport for you and adds it all to one bill or: buy the goods at one place, and the shipping somewhere else –Find the video at a web-place, then yourself order a connection with right QoS, and start sending the video

29 Other business roles and relations Other roles may be added –’hotel’ (web-hosting), PKI, … Why the supermarket model in fig. 4.3? –Central role for the ’retailer’ (e.g. Telenor, Vodaphone) –Retailer has main relation with the customer, incl. Personal profile ( credit card info, preferences,…) –May allow ’single logon’ Less passwords to maintain for the customer –3rd parties may ’hook into’ this information But only if they have relation with retailer, and if customer allows