Firstly, don't tell me this is the wrong forum, because the ss7 tag doesn't exist on network engineering, and this isn't a security question; also, you'll find questions like this on SO.
This answer claims that E1 with CAS has 31 bearer channels, and CCS, 30B+D, which means he is implying that CAS refers to only in-band signalling, i.e. robbed bit signalling.
This contradicts that and claims that CAS refers to in-band (31B) and out-of-band (TS16 signalling, 30B+D). It also refers to out-of-band CAS as 'Channel Associated'.
This suggests there are three CCS variants, one being Channel Associated.
Common Channel Signalling (CCS)
Channel-Associated
Quasi-Associated
Non-Associated
Is there a difference between out-of-band 'Channel Associated' CAS and 'Channel Associated' CCS or is it the same thing? Perhaps 'Channel Associated' CCS refers to a separate lone E1 carrying signalling links separate from the voice E1 bundle (31D and 31B); then again, the image for it depicts only a single circuit for the signalling, which would be 30+D, which is out-of-band CAS...
To make matters worse, this shows CCS to be what the previous source classed as Quasi-Associated CCS and draws the dichotomy with CAS, ignoring the existence of the apparent 'Channel Associated CCS', suggesting that CCS is exclusively Quasi-Associated and refers to the existence of separate STPs, whereas CAS refers to a lack of separate STPs.
Can someone clear up this ambiguous terminology and arrive at proper distinctions? It seems nobody knows, as the sources use conflicting classifications.
There are only 2: CCS and CAS. CCS refers to Common Channel Signaling, meaning that the link with signaling (protocol independent) may or may not be in the E1. CAS refers to Channel Associated Signaling, were the channel with the signaling IS in the E1.
E1 CAS refers to the E1 with a fixed TS for signaling, like MFC:R2 which uses time slot 16 for line signals (4 bits Tx, 4 bits for Rx, mostly only used only 2 bits called A and B). Usually some people may refer to this as 30B+D, but it's not correct due that term is tied to ISDN PRI, where 30 TS for Bearer plus 1 TS Data. Normally the switch will reject the creation of a PRI on top of a CAS interface, because the D channel on EuroISDN PRI is 16, as well as MFC:R2, hence ISDN PRI is only CCS. However, you can create SS7 CICs in the same E1 created as CAS (also normally use TS 16 to control echo cancellers or DCME's for international long distance over TDM) very well documented in the old Siemens EWSD switch.
E1 CCS refers to the interface with 31 TS available to be used for CCS circuits, but mostly for SS7 links and CICs (or even B channels). You can create the SS7 link in any channel you want (in TDM switches you need to create a semi-permanent connection to reach a link processor), as well as the CICs.
What you are referring as Associated and Quasi-associated is the way as you connect the SS7 link with the network, but nothing to do with the physical interface definition. When a SS7 link is connected in associated mode, means that you know the SPC (Signaling Point Code) from the switch adjacent, and only that SPC. All the signaling is between those switches and nothing else (usually only ISUP).
Quasi-associated means that your link is connected to STP (Signaling Transfer Point), who serves as signaling router to reach other SPCs in the network. So you can have some CICs between switch A and B, but the signaling link is not connected directly in the same way as the CICs, instead you send the messages from the switch A to the STP to reach the switch B, but also you can send any message to any node in the network (if is allowed), as well as dialogs for transaction with DB (TCAP) or Mobile (MAP).
Funny note, there were some old implementations of EuroISDN PRI were you can manage several PRI E1 with just one link in the same way as SS7 does, but I've seen very few of those cases. This is also well known in the EWSD as PA Slave (Primary Access Slave).
Hope this helps.
Related
I am new to DDS domain and need to have the below understanding.
how to publish common topics between two vendors to achieve interoperability in DDS?
The Scenario is :
Suppose there are two vendor products V1 and V2. V1 has a publisher which publishes on topic T1. V2 wants to subscribe for this topic.How will the Subscriber(V2) know that there exists a Topic T1?
I have a similar doubt on Domain level.how will a subscriber know to which domain it has to participate in?
I am using OpenDDS.
Thanks
Interoperability between vendors is possible, and regularly tested/demonstrated by the main vendors.
You will need to configure your DDS implementation to use RTPS ( I think RTPS2 currently), rather than any proprietary transport that vendors may use. This might be enabled by default.
In terms of which domain to participate in, you programmatically create a domain participant in a particular domain (which domain it connects to might be controlled by a config file) and all further entities (publishers, subscribers, etc) that you create then belong to that domain participant and therefore operate in that domain
To build on #rcs's answer a bit... the actual amount of work you have to do can depend on DDS implementations (OpenDDS, RTI, Prismtech...) because they'll have different defaults. If you use the same on both ends, then your configuration becomes a lot simpler since defaults should line up for things like domain and RTPS.
You will need to make sure the following match:
Domain ID
Domain Partion
Transport (I recommend RTPS, FWIW version difference between 2.1 and 2.2 hasn't mattered in my experience)
TCP or UDP
Discovery port and data port - this will matter more or less depending which implementations you use and whether or not you're using the same one on both ends of the connection, if use using the same, they'll have the same defaults.
Make sure the topic one publishes matches the topic the other subscribes to, this will apply to the Topic and the Type (see more here)
Serialization of the data
Discovery (unicast vs. multicast, make sure
whatever setup you choose is valid, ex: both devices are in the same
multicast group)
QoS settings will need to line up, though I think defaults will likely work (read more here)
Get the Shapes demo working between the machines you're working on first, this does some basic sanity checking to know that it is possible with the given configuration and network setup. Every vendor/implementation that I've seen has a shapes demo to run, for example, here is RTI's.
That's all I can think of right now, hope that helps. I have found DDS documentation to be really good, especially if you know when you can (and when you can't) use any vendor's documentation's answer for your implementation (ex: answer found on RTI's doc or forum and whether or not it works for your OpenDDS application). Often the solutions are similar, but you'll find RTI supports the most and RTI + Prismtech have some of the best documentation.
The DDS RTPS protocol exchanges discovery information so that different applications participating in the same domain (!) know who is out there, and what they are offering/requesting. You need to make sure that the two applications are using the same domain ID (specified on the domain participant). Also, as some implementations allow for different transport options, make sure to use RTPS (sometimes called DDSI) networking.
The RTPS specification contains a mapping from domain ID to port numbers, so if applications from different vendors use the same ID it should just work. Implementations might however override portnumbers with configuration.
To maximize the chance that the applications communicate properly, ensure they use the same IDL datamodel. Vendors have different approaches to type evolution / mapping types that don't exactly match, and not all of them implement the XTypes specification (yet).
Also, as some implementations are stricter than others, ensure that you stay within bounds of the specification. This means that a topic name should only contain alphanumerical characters (I sometimes see ':' to indicate scoping, that is not allowed).
Things that will definitely not work between vendors is TRANSIENT/PERSISTENT durability or communication over TCP, as both have not been standardized yet. TRANSIENT_LOCAL should work. The difference between TRANSIENT_LOCAL and TRANSIENT is that with TRANSIENT_LOCAL, data is no longer aligned after a publisher (writer) leaves the system, whereas with TRANSIENT that data will still be available.
Also note that for API-level interoperability between vendors, your best chance is to use the new isocpp API, since that one has been implemented pretty consistently across the vendor implementations I've seen.
Hope that helps!
I use a PBX with a Sangoma card, specifically the A500. Below is the link for the product
http://www.sangoma.com/products/a500-2-24-port-scalable-st-bri/
On the link you have a demo, which breaks down the components and explains them nicely. One things it also shows (specifically on step 3), is that the BRI module can be inserted either way, however one way is for TE and the other for NT.
I understand that TE stands for Termination equipment and that NT stands for Network Termination. But cannot seem to find any decent information that actually tells me what each of these mean and the difference between them. Could someone point me to a site or resource with this info, or explain it simply for me if you know the answer.
ISDN BRI defines different points or interfaces along the link between the telephone exchange and the end equipment in, for example, your home.
At the user equipment end, ISDN also distinguishes between different types of 'Terminal Equipment' - for example TE1 refers to specialised ISDN terminals and TE2 to 'standard' phones.
At the interface point between the line from the telephone exchange, and the local ISDN Terminal Equipment in your home, the Network Termination (NT) provides the functionality to interface between the 2 wire connection from the telephone exchange (i.e. the 2 wires that come in to your home) and the 4 wires connections to ISDN Terminal Equipment (e.g. the 4 wire connection that you plug into your ISDN phone).
Some good links to give some background:
http://homepages.uel.ac.uk/u0113650/ISDNBASIC.htm
http://docwiki.cisco.com/wiki/Integrated_Services_Digital_Network
http://www.networkmuseum.net/2011/07/isdn-bri.html
I was trying to understand the difference between Transport security and message security from the below link and came across the following content.
The http://msdn.microsoft.com/en-us/library/ff648863.aspx says that
When using transport security, the user credentials and claims are passed by using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentication options compared to message security.
Can someone please explain me the meaning of above statement with an example if possible ?
It has mainly two parts which I could not understand :
user credentials are transport-dependent.
allows fewer authentication options compared to message security.
If you read further in those article, you yourself might be able to make out.
If you see TCP/IP or OSI Layers of the Protocol suit you will notice that upto Transport layer communication is mostly dependent on communication mechanism. The protocols of Transport layer are limited (HTTP, TCP, IPC, MSMQ) for transporting of data. They transport all the data in same manner irrespective of the type of data. Here the channel that is transporting is made secure.
On the other hand in message level security, it is message that is secure. You can use any type of mechanism to encrypt / authenticate your message, and in this case Transport level security provides added advantage.
In simple term, A, B and C are three persons. A wants to send a message to C and B is transporter of the message. If A send his message in a simple envelop, then the message is as secure as the transporter that is B. But if A send a message locked in a box and only C has its key, then his message is secure as B plus it has security of the locked box.
Hope this helps.
Further going with the above analogy, if the transporter B is say your postal service, then A has limited options of having security and limited flexibilty to change B's security provision as those are decided by another party (the Postal Department). But in case you are sending a locked box, the locking mechanism is your choice, you have flexibility to choose type of lock of your own choice as long as C agrees and can open it.
I have 3 simple questions.
What is the Diameter protocol in simple explanation?
Why is it used?
How can one use it?
I have searched the net for a practical explanation but couldn't find one. All there is, is some technical blabber.
Per the ITU, DIAMETER is the successor to RADIUS (twice as good). No, it's not a joke. RADIUS was, and is still used, in many telecommunications networks as the interface to the authorization, authentication and accounting protocol server (typically just called the AAA). The problem with RADIUS is that:
It's built on UDP -- RADIUS packets can just drop off.
It was never designed to handle much more than short, attribute/value pairs.
While it is extendible, it's limited to vendor-specific attributes (VSAs)
Theses were all wonderful back with Livingston incorporated made the Portmaster terminal/modem server. (Ah, back in the day... I can hear the telebit trailblazers now...) But that was when 19.2Kb UUCP was cool.
DIAMETER aims to address these issues for the modern world. First, it's based on TCP. This addresses the drop-out problem. We now know that packets don't get there "half way". We can also encrypt streams. It's also, courtesy of TCP, capable of having much larger attribute sets (we call them AVPs). Thus, it's much easier to convey value sets beyond the simple key/value pair.
As an example, in DIAMETER< you can do a login request, sending far more than a username/password. You can send the course location for example, telling the AAA where the user is at login (maybe there are geo-location rules for access). And, because we have a more robust, richer language to say things in, the AAA can convey, not only the yes/no, but the rules for a given yes, or the reasons for the no.
Does this help?
I found this complete article on Diameter protocol written in IBM website.
Introduction
The Diameter protocol was derived from the RADIUS protocol with a lot
of improvements in different aspects, and is generally believed to be
the next generation Authentication, Authorization, and Accounting
(AAA) protocol. The Diameter protocol was widely used in the IMS
architecture for IMS entities to exchange AAA-related information.
Because the IMS system might be the next big thing in the telecom
industry, we believe a clear understanding of the Diameter protocol is
necessary for understanding the essence of the IMS architecture. This
article offers an overview of Diameter and how it works. For
developers interested in how AAA in IMS works, or who want to
implement Diameter applications, this article is a good starting page.
With the emergence of new technologies and applications such as
wireless networks and mobile IPs, the requirements for authentication
and authorization have greatly increased, and access control
mechanisms are more complex than ever. The existing RADIUS (Remote
Authentication Dial-In User Service) protocol can be insufficient to
cope with these new requirements; what's needed is a new protocol that
is capable of fulfilling new access control features while keeping the
flexibility for further extension. This is where the Diameter protocol
comes into play.
Diameter is a Authentication Authorization and Accounting (AAA) protocol. It works on the Application Layer if we consider OSI Layered model.
Example of AAA protocol:-
Any User trying to access a Network (Ex: Internet Service Provider) has to undergo "AAA" procedure that is being implemented by that Network.
1. Authentication: The network will validate that its an Authenticate User.
2. Authorization: The network will authorize the services requested by the User.
3. Accounting: The network will keep a track of usage made by the User.
While performing the above three steps, the Network may reject the User from using the service at any point and that is how security is maintained and hence the importance of AAA protocol.
So, Diameter basically is a message based protocol, where AAA procedure may occur and the AAA nodes exchange messages and receive Positive/Negative acknowledgment for each message exchanged between nodes.
In addition to IBM’s article “Introduction to Diameter” already mentioned by Hamed in a previous answer, Cisco’s article “Authentication, authorization, and accounting overview” also has some interesting information about Diameter, comparing it to RADIUS.
“Authentication identifies a user; authorization determines what that user can do; and accounting monitors the network usage time for billing purposes.” … “Diameter is the next-generation AAA protocol and overcomes (several) RADIUS deficiencies.”
“The RADIUS protocol carries authentication, authorization and configuration information between a NAS and a RADIUS authentication server.” (In this context, a NAS is a network access server, a gateway providing access to a protected network.) … “Implemented by several vendors of network access servers, RADIUS has gained support among a wide customer base.” RADIUS has codes for a limited number of attributes (including user name and password, service type, login information, etc.), so developers took advantage of its “vendor-specific attribute” (VSA) to exchange custom data, extending (in a proprietary manner) the scope of RADIUS, yet staying within its restrictions (e.g., attribute value no longer than 253 bytes). So, why use Diameter? Diameter offers much greater flexibility (longer data field, expandability, capability negotiation), higher performance (“32-bit alignment”), greater reliability & availability (TCP and STCP support, better acknowledgement mechanism and error messages, failover), increased security (“end-to-end security”), etc.
Just like FreeRADIUS implements a FOSS RADIUS server that you can install on a server so that your other applications and devices (e.g., a Wi-Fi access point or wired switch performing 802.1X authentication) can interact with it, FreeDiameter is a FOSS Diameter framework that you can install on a server. However, while TMCNews’ article “The Role of Diameter in IMS” (2007) mentions that “Diameter has been heavily adopted by the 3GPP in the IMS standards set”, I haven’t seen any consumer- or small-business-grade application or device that makes use of Diameter. On the other hand, Diameter is reportedly “backward compatible with RADIUS to ease migration” (Cisco), through a “translation agent” (IBM). For example, FreeDiameter has an extension, the “RADIUS/Diameter extensible gateway” (app_radgw.fdx), whose “purpose is to allow a RADIUS client to work with a Diameter server”. However, the documentation also warns that the “translation of RADIUS messages to Diameter is quite a complex task. It is likely that the translation plug-ins need some fine-tuning to fit your particular needs.”
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.