1. Home
  2. Telecom Technical
  3. SS7 embedding in E1

SS7 embedding in E1

Hi!

I'v started reading G.70x and Q.70x in order to learn a little bit about SS7 networks, however I have still one issue open:

Each E1 frame consists of 32*8 bits. In most cases timeslot 16 is used for common channel signaling. However I can't find information about how are SS7 frames embedded in E1 frames.

Is it like this, that bits from time slot 16 from each E1 frame should simply be treated as continous bit stream, and HDLC framing should be used on this bit stream ? And this means that MTP1 frame boundries can fall somewhere in the middle of time slot bits, and it is perfectly ok (as HDLC frames may have a length that is not a multiple of 8), right ?

Best Regards, Przemyslaw

Reply to
Przemyslaw Wegrzyn
Loading thread data ...

Hi Przemyslaw,

Nice reading you got yourself into :-))

Your view of the SS7 frames is quite correct. With respect to E1 timeslot content for SS7 it is indeed just a bit stream of HDLC frames. Due to "0" bit stuffing by HDLC, frames can start anywhere with respsect to the E1 frame. Note however that the original SS7 content (FISU, LSSU and MSU) is always an "integral number of octets" as the SS7 specs tells us.

Marten

snipped-for-privacy@czajsoft.pl (Przemyslaw Wegrzyn) wrote:

Reply to
Marten Rooimans

Since both posts were EU, I would add that SS7 usually refers to the US (NANP?) variant of C7. There are a number of different flavors of this protocol. There is an international version used between gateway switches, and national versions for a number of countries. If you really understand one, the rest are pretty simple, but differ in more or less small ways, e.g. US SS7 extends the length of the point code field. National flavors of C7 generally support more features than the international version.

Reply to
John McHarry

Heh, my current job is development of Intelligent Network services, so I'm not afraid of ITU-T/ETSI norms. However most of the time I only need INAP/CAP. Recently I've decided to learn a little bit about lower layers :) I will probably have more questions, after further reading.

That's good. However it wasn't so obvious to me after (ok, briefly) reading the norms. If this is explicitly stated somewhere, could someone point me to the right chapter of the norms ?

Best Regards, Przemyslaw

Reply to
Przemyslaw Wegrzyn

Yes, I'm aware of the differences. I currently work at Siemens as IN service developer. We use higher level API for SS7, so I do not have to fight with lower level differences, but I can quite frequently observe INAP/CAP-level incompatibilities between MSCs from Ericsson/Nokia/Siemens.

Best Regards, Przemyslaw

Reply to
Przemyslaw Wegrzyn

ISO 3309 (which I think is the ultimate reference for HDLC- all the other standards seem to refer back to it) treats bit-stuffed (as opposed to byte-stuffed) HDLC as being transported by a bit stream. They don't mention any particular octet alignment, therefore none is needed. Higher level protocols sitting on top of HDLC usually have message lengths that are an integer number of octets, but (as Marten R. pointed out) this won't necessarily translate to an integer number of octets after stuffing.

Regards, Allan.

Reply to
Allan Herriman

Just a little point of clarification may be needed here.

In E1, timeslot 16 is commonly used for Channel-Associated Signaling (CAS) on voice circuits. The content of TS16 in this mode is the ABCD signaling bits associated with each of the other 30 timeslots. TS16 can also be used for Common-Channel Signaling (CCS) or any user-defined clear-channel 64Kb/S data stream, just as any other timeslot can.

- Steve Pinkston Kentrox TAC

Reply to
Kentrox TAC

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.