Your SlideShare is downloading. ×
0
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
SUA Tutorial
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SUA Tutorial

2,172

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,172
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • IPSEC does not work if the SCTP association is terminated within the NAT, IPSEC works only till the NAT border. A NAT box has to change addresses and portnumbers in the IP and transport header. IPSEC has authenticated or encrypted at least the transport header so changing this would break the association. This can be circonvented by tunneling.
  • Transcript

    1. SUA tutorial SCCP User Adaptation Layer tutorial Authors: Lode Coene Gery Verwimp
    2. SCCP user adaptation layer(SUA) <ul><li>- replaces the functionality of SCCP and M3UA over SCTP in an IP network </li></ul><ul><li>- required for 3G mobile networks (from Release 5 onwards) -> Nokia, Ericsson </li></ul><ul><li>- also applicable for IN (TCAP over IP) </li></ul><ul><li>- runs on top of SCTP </li></ul><ul><li>- standardization in stable mode </li></ul><ul><li>- Transport Independent SCCP is a direct competitor (ITU-T) </li></ul>IP SCTP M3UA adapts MTP 3 User Parts to SCTP SUA adapts SCCP Users to SCTP Application ( +TCAP) ISUP, SCCP classic SS7
    3. SUA status in IETF & outside <ul><li>new draft 09 (November) </li></ul><ul><li>Applicability of SUA: </li></ul><ul><ul><li>Mobility Management in Wireless 3G systems (MAP) </li></ul></ul><ul><ul><li>IN services for fixed and wireless systems (INAP, CAP) in circuit switched and VOIP systems </li></ul></ul><ul><ul><li>SMS offloading </li></ul></ul><ul><ul><li>Iu interface (UTRAN/GERAN: between radio access and core network) </li></ul></ul><ul><ul><li>Corporate GSM </li></ul></ul><ul><ul><li>Signaling Gateways </li></ul></ul><ul><ul><li>Signaling Relays </li></ul></ul>
    4. Basic SUA Network architecture A1 B1 B2 C1 D1 D2 E1 gt gt gt’ gt’ gt’’ relayNodeEntitySet gt’’’
    5. SUA network architectures <ul><li>Basic SCCP/SUA architecture: to have end-to-end communication between different entities (SGSN, HLR, SMSC…) independent from the underlying technology used (TDM, IP, ATM…) </li></ul><ul><ul><li>PSTN – IP interworking </li></ul></ul><ul><ul><li>all IP network </li></ul></ul><ul><li>How should Global Title Translation be done </li></ul><ul><ul><li>Distributed : use of local GT databases </li></ul></ul><ul><ul><li>Central : remote database accessed via LDAP… </li></ul></ul><ul><ul><li>Hierarchical : remote database accessed via DNS… </li></ul></ul>
    6. PSTN – IP interworking Warme Farben Kalte Farben Vorzugsfarben 4 × Grau (aus 216)
    7. PSTN – IP Protocol Interworking Warme Farben Kalte Farben Vorzugsfarben 4 × Grau (aus 216) HLR or SCP within an IP network IP-based Network PSTN MSC (or SSP) Signalling Gateway SUA SCCP Interw. SCTP IP MTP 1-3 HLR (or SCP) MTP 1-3 MAP/INAP TCAP MAP/INAP SCCP TCAP SUA SCTP IP
    8. SGSN HLR SMSC SRP SRP SRP Association: Protocol Stack : SRP . . . . SCTP IP AAL5/Ether ., ... SUA SUA AAL5/Ether IP SCTP SUA SCTP IP AAL5/Ether MAP, IN, RANAP... Network border
    9. SUA implementation architecture <ul><li>SUA runs as a User plane implementation in Linux </li></ul><ul><li>makes use of the Siemens SCTP implementation ( www. sctp .de ) </li></ul><ul><li>uses the SCTP “function callback” mechanism </li></ul>
    10. SUA : supported features Routing Options for Connectionless Services <ul><li>routed on IP address & SSN </li></ul><ul><ul><li>Supply the origination an destination IP address </li></ul></ul><ul><ul><li>Supply the application Subsystem Number(SSN) </li></ul></ul><ul><ul><li>Message will be routed onto the correct SCTP association towards the destination IP address (= direct associated routing) </li></ul></ul><ul><ul><li>It might turn out that there is no direct SCTP association between the local SUA node and the destination SUA node, then SUA will use quasi-associated routing (wow route via intermediate SUA nodes based on IP address) </li></ul></ul><ul><li>routed on Pointcode & SSN: </li></ul><ul><ul><li>same as IP address & SSN, but different address syntax (32/128 versus 14/24 bit) </li></ul></ul><ul><li>routed on GT & SSN </li></ul><ul><ul><li>Supply the origination (= calling party) and destination (= called party) Global Title (or Hostname in case of extended AMF) address </li></ul></ul><ul><ul><li>Supply the optional application SSN </li></ul></ul><ul><ul><li>Message will be routed onto the correct SCTP association towards the destination IP address derived via Global Title Translation (GTT). </li></ul></ul><ul><ul><li>If no direct association exists , then SUA will route via intermediate SUA nodes based on the IP address. </li></ul></ul>
    11. SUA : supported features Connection Oriented Services <ul><li>Connection oriented service </li></ul><ul><ul><li>only protocol class 2 </li></ul></ul><ul><ul><li>association of connection sections is not supported </li></ul></ul><ul><li>Same routing options for CORE (COnnection REquest) as for the connectionless messages. </li></ul><ul><li>Routing for subsequent msgs of a SUA connection is done using the stored association Id in the SCOC TCB, thus routing based on IP address or GT is not done. </li></ul>
    12. SUA : supported features ASP Management <ul><li>reachability of endnodes/ application servers : ASP management </li></ul><ul><ul><li>ASP : application server process </li></ul></ul><ul><ul><li>AS : application server: </li></ul></ul><ul><ul><li>An Application Server contain at least one ASP. The ASP within the Application server can be processing traffic or can be in standby. The way in which traffic is shared over the ASP of a AS is implementation dependent. However traffic that needs the same server (such as TCAP msgs belonging to the same transaction) must be sent to the same ASP, if possible. </li></ul></ul><ul><ul><li>An ASP can belong to different Application Servers </li></ul></ul><ul><ul><li>If a ASP would fail then internal mechanisms have to provide for the transfer of state (example state of TCAP/application transaction.) within the AS. </li></ul></ul><ul><ul><li>A more global solution will be provided using Rserpool technology. </li></ul></ul><ul><li>comparison with M3UA </li></ul><ul><ul><li>ASP management is identical for all UAs </li></ul></ul>
    13. SUA : supported features ASP Management <ul><li>Difference between SS7 management and ASP management </li></ul><ul><ul><li>ASP management only deals with adjacent nodes </li></ul></ul><ul><ul><li>SS7 management indicates statuses from non-adjacent nodes or routes (STP) </li></ul></ul><ul><ul><li>Indicates to a ASP to start/stop sending traffic to the SG for a specified DPC and SSN </li></ul></ul><ul><ul><li>Also congestion levels may be exchanged with the ASP </li></ul></ul><ul><ul><li>SS7 management is in principle only used for interworking between a PSTN and a IP network, but is also extendable to an all-IP infrastructure (single node = combined SG and AS) </li></ul></ul><ul><ul><li>Still requires the use of a pointcode overlay of the all IP network </li></ul></ul><ul><ul><li>SS7 management gives the impression that the SG+ASP’s is a SS7 node(end/relay) towards the SS7 network. </li></ul></ul><ul><li>Error and notify msg </li></ul><ul><ul><li>Use is still not very clear, e.g. their effect on ASPSM/ASPTM procedures. </li></ul></ul><ul><li>Dynamic registration of ASP to a SG </li></ul><ul><ul><li>Should be treated as extremely dangerous, especially if this is extended to the peer-to-peer IPSP - IPSP case (double-ended registration). Interop seems very doubtful here. </li></ul></ul>
    14. SPCx SCMG SPC1 SG SPC2 ASP1 SPC3 ASP2 AS SS7 network or SG + AS(P) IP network SSy SSz SSb SSb
    15. SUA uses a digit pattern which is translated from node to node until the final destination is reached -> Global title (e.g. MSISDN number : CC + NDC + SN) Global title aspects IP network Operator 1 IP network operator 3 IP network operator 2
    16. SUA : supported features Relay service : provide GTT (AMF ?) service <ul><li>Useful for NAT crossing : no unknown NAT middlebox needed. The relay point is the box and it is explicitly visible towards other SUA relay points or SUA endpoints in both the normal internet and the NAT. </li></ul><ul><li>Can be used as a firewall for SUA traffic : example removal of SMS spam traffic, enforcement of roaming agreements, ... </li></ul><ul><li>If relay point is used for transitioning into the NAT then IPSEC can be used. Expands the addressing capabilities </li></ul><ul><ul><li>E164 to E212 </li></ul></ul><ul><ul><li>E164 to hostname </li></ul></ul><ul><ul><li>Hostname to hostname </li></ul></ul><ul><ul><li>hostname to E164 </li></ul></ul><ul><ul><li>IPv4 - IPv6 network or NAT border crossing </li></ul></ul><ul><ul><li>Pseudo end-to-end :network architecture hiding </li></ul></ul><ul><li>Allow for loadsharing across a pool of relay points (using Rserpool or own SUA built in protocol) </li></ul>
    17. Use of ENUM in SUA A1 B1 B2 C1 D1 D2 E1 gt gt gt’ gt’ gt’’ relayNodeEntitySet gt’’’ DNS A DNS X DNS B DNS DNS DNS root
    18. SUA: supported features Building the GT tree of the relaying service via DNS(ENUM) <ul><li>Normal way of using DNS is to invoke GetHostname for every message that passes: More negative points than positive </li></ul><ul><ul><li>would create a DNS message flood in the DNS system as all connectionless msgs use E164/E212 numbers(if numbers gets cached, this problem may be reduced , but raises other issues) </li></ul></ul><ul><ul><li>the response time from the DNS is unpredictable due to its hierarchical architecture. Would produce a WWW(world wide Wait) effect on SS7 traffic </li></ul></ul><ul><ul><li>Using the Time-to-live(TTL) from the DNS records is quite useless as SUA would have a direct connection with the remote SUA node(and thus know far much better if the remote side is active or not). That would mean that SUA should not be caching the DNS info but always have the up-to-date info of all its adjacent SUA peers. </li></ul></ul><ul><ul><li>Is less flexible than the standard Global Title Translation function: a DNS name when distributed in DNS will always map to the same set of IP addresses (= SUA nodes) independent from the place where the resolving is requested, which would lead to a SUA hierarchical network design, something that is very BAD for reliability and contrary to any SS7 network design up till now(SS7 favors greatly a peer-to-peer network design and SS7-over-IP should benefit from that) </li></ul></ul><ul><ul><li>A name in the DNS can return many IP addresses and not all those address may belong to the same. node -> DNS is sometimes used for loadbalancing across multiple nodes and it is impossible to make a difference between a truly multihomed (SUA)node and a a bunch of replicated (SUA) nodes(with no multihoming attached to each single node naturally) (Except if you start finding it out for yourself by setting up association with each of the addresses) </li></ul></ul>
    19. Use of SUA with SCTP <ul><li>Association setup, release, mapping (distribute traffic over different associations according to addressing info), SSN, portnumber </li></ul><ul><li>Difference between end and relay point. </li></ul><ul><ul><li>static associations </li></ul></ul><ul><ul><li>dynamic associations (pure end-to-end) </li></ul></ul><ul><li>ASP issues -> relation to Rserpool </li></ul><ul><li>TESTIP: Basic tester for testing the capabilities of SUA </li></ul><ul><li>Not compatible (yet) with the EWSD based TEST User part </li></ul>
    20. Comparison with other stacks (1) <ul><li>SUA <-> SCCP+M3UA </li></ul><ul><ul><li>SUA has better knowledge of the underlying network than SCCP on top of M3UA, I.e. the Routing Contexts can be more fine-tuned. </li></ul></ul><ul><ul><li>Management should be simpler as only one layer (SUA ASP management) has to be administered versus 2 (M3UA ASP management + SCCP management). </li></ul></ul><ul><ul><li>Can use extended addressing capabilities which are not included in SCCP (use of IP address and of hostname/DNS names) yet. </li></ul></ul><ul><ul><li>SUA does NOT require SS7 pointcodes (administrative) in principle, but the traditional SCCP users may still require PC or SSN status indications ... </li></ul></ul>
    21. Comparison with other stacks (2) <ul><li>SUA <-> transport independent SCCP </li></ul><ul><ul><li>Just as SUA, TI-SCCP would lack the MTP3 transfer functionality and point code overlay to support traditional management procedures, if run directly over SCTP. </li></ul></ul><ul><ul><li>TI-SCCP can be run over M3UA as well, via the appropriate STC. </li></ul></ul><ul><ul><li>TI-SCCP doesn’t have extended addressing capabilities yet. This may change but is up to TI-SCCP standardisation (example IP address/hostname/DNS name) </li></ul></ul>
    22. SUA applicability <ul><li>SUA can transport bigger SMS messages (nr of char >> 160) </li></ul><ul><ul><li>however, this would also be true for traditional SCCP and TI-SCCP, but requires adaptations to MAP protocol and raises interworking issues </li></ul></ul><ul><li>SUA can transport bigger messages for all its applications </li></ul><ul><ul><li>particularly useful in all-IP, where segmenting/reassembly can be left to SCTP </li></ul></ul><ul><li>SUA is less complex than M3UA+SCCP, but has extended features </li></ul><ul><ul><li>… because it can be fine-tuned to SCCP applications </li></ul></ul><ul><li>SUA supports the basic IP addressing architecture and DNS naming </li></ul><ul><ul><li>this advantage depends of course on applications using the extended addressing capabilities </li></ul></ul>
    23. 1st SUA bakeoff 5 – 9 November 2001 <ul><li>Done at Siemens atea, Herentals Belgium </li></ul><ul><li>5 Companies attended: Performance Technologies(PTI), Radisys, Hughes Software Systems(HSS), Cisco and Siemens </li></ul><ul><li>No big problems detected with spec </li></ul><ul><li>Most implementations only supported Connectionless and were acting as Signalling gateway </li></ul><ul><li>Connection-oriented worked also -> to be used in 3GPP?? </li></ul><ul><li>Basic SUA Management worked. </li></ul>
    24. Conclusion <ul><li>Bug reports, suggestions, support can be directed to: </li></ul><ul><ul><li>Lode Coene: Email: Lode.Coene@siemens.atea.be, phone: +32-14-252081 </li></ul></ul><ul><ul><li>Gery Verwimp : Email: Gery.Verwimp@siemens.atea.be, phone: +32-14-253424 </li></ul></ul><ul><ul><li>Implementation is open source , may be used, changed, whatever. If you have a great idea to be use d in SUA, let us know, we ‘ll consider it for a next version. </li></ul></ul><ul><ul><li>Source is to be released under the GPL on the web: www.sctp.be /sua </li></ul></ul><ul><ul><li>Thank you </li></ul></ul>
    25. ... And now for something completely different... GSM goes around the world SS7 makes it work ..And SMS is the mobile data revolution.. http://www.sctp.be/sua http://www.sctp.de

    ×