Pakistan to buy Chinese AWACs?

maglomanic

I think China or any other country has a hard time when they are takeing several countrys technologys and trying to intergrate it into one system. Not to mention there own.

maglomanic said:

I was under the impression that Chinese systems have Link 16. I would consider it very much possible. Chinese have tried to stick to western standards as much as they can. China was buying Phalcon which is a western system. The chinese AWACS program is inspired by the whole Phalcon dabacle. I would think that what they created or atleast tried to adhere to what they saw in Phalcon. But then again like you said there havent been any reports regarding Chinese link 16.
Regarding your network example, i have programmed in winsock and done lots of network programming. As long as you have native api for two different hardwares (considering the standard bus MIL-STD 1553B even China uses i think that makes it even simpler for their hadware to talk to western systems). Worse come worse, you need an emulator that would take more resources but can over come seamless hardware connectivity problems.

Click to expand...

I'm not sure USA would let China have the specs for link 16.

I don't think you get what I meant by networking. When you do programming through winsock, you are using existing network protcol like TCP/IP and such. When you use the drivers for those protocols, you get send and receive function prototypes, so you know what to call, but you don't know the implementation of these send/receive.

In any kind of network communication, there are probably 6 or 7 layers. But only about 4 well known layers: application, transport, network and link. You are basically normally programming at application level. If you are really hardcore, you might get to program the transport level drivers (UDP, TCP), very few people know what's going on a network level (IP, ...), let alone link level. If you have one side sending at transport layer with TCP and the other side receiving with UDP. It's never going to work.

In any kind of data link, the protocol developers have to think about the following:
1. how big are the header size
2. how big are the data size
3. what format are the packet sent
4. how to ensure that the packet if received by a malicious party, cannot be decrypted.
5. how to ensure that the packet will eventually be sent to the receiving side (ie: how to guarantee delivery of data)
6. how to ensure that malicious party cannot fake sending a packet, how to distinguish between a good and a tampered packet.
7. if successfully sent a packet, how to proceed from there and if failed sending a packet, what to do.

basically, in order to achieve LPI and resistance toward jamming, you will have to reduce the packet size (so, you get less collissions of your packets and harder for opponent to recognize that you sent real data).

But if you do this, you have to sacrifice the data size (which would result in lower data rate) and/or header size (less information for receiving side, header size normally cannot go too low).

In order to guarantee delivery, you have to have certain header fields to indicate what the current count of delivery is and how many retries, and size of packet and several other information to be delivered. So, header size can never be too little.

And then there is the idea of frequency hopping. You send the first packet at certain frequency, and then you have to have a good algorithm to indicate to the receiver where the next packet is coming in at. (although, the actual process of recognizing packets is at link layer, I haven't really studied it and then there is the good old physical layer). Basically, when the other side is jamming you, you are going to have a lot of trouble sending packets through. There are different protocols in which you can deal with jamming. And the Chinese one is probably different from Link-16. If China knows exactly how link-16 works, China would be able to explore certain weaknesses in it. For example, maybe link-16 is weak against malicious party sending garbage data to it and such. Chinese jammers could exploit this if it exists.

As for phalcon, China could easily put its own transport layer driver on Phalcon. The Israeli software would only need to operate at the application level and use the interface given by China to interact with the transport layer. And then the Chinese data link would do the rest of the work.

It goes like
application->transport->network->link->physical
receive on the other side physical->link->network->transport->application
a lot of passing data around.

for a quick reference, you can check the 7 layers of OSI model

Tp,

I know about OSI model (from like 3-4 years ago when i first enrolled in my computer science bachelors program).

See here is the thing. Link 16 is just a standard. How you implement it totally depends on the vendor. Each layer that you described could be implemented by seperate vendors differently as long as they adhere to the standard's requirements.

Lets say there is a requirement for a resend function. Specification of it's arguments and return value down to performace throughput. As long as a vendor is able to adhere to those requirements it doesn't matter what tool they used or what algorithem they designed. Thats the basic idea behind information hiding and exposing the interface (similar to the whole class constructs deal in OOP).


Now back to the link 16 deal, you can have two implementations of the same protocal but might not give you what you are looking for in terms of performance subjective to your environment and platform. For example, i have a wireless card designed by intel. My windows driver works just fine with it but it works super fine the driver intel provides. Now both vendors can design software for the same hardware knowing that it's fabrication adheres to certain standard. But performance wise you would need to know your hardware better.

Incase of Chinese AWACS it is their hardware they know it inside out. WHat algorthem they use to adhere to link 16 requirements shouldnt be a biggie as long as it's their hardware. Reverse engineering someone else's hardware is also doable and possible (i have a reverse engineered driver on my linux installation which is just as good as intel's but requires me to do a lot of customization and ease of use sucks).

just a link which describes some high level requirements for TDIL-J or Link 16
http://www.rand.org/pubs/monograph_reports/MR1235/MR1235.chap9.pdf#search='TADILJ%20standards'

Here is the refernce for J message standard that is used by Link 16. Specs down to every bit.

http://www.c2oa.mccdc.usmc.mil/cole/Appendix/AppendixIV.pdf#search='J%20message%20format%20standard'

Source:

Air Force monitors Chinese Spy Plane at Pakistani Air Base
Dated 25/8/2006

The Indian Air Force is monitoring the presence of a Chinese surveillance plane at the Chaklala air base in northern Pakistan, newspaper reports said on Friday. The aircraft reportedly flew in with a group of Chinese aeronautical scientists in July end 2006.

The classification of the spy plane is said to be the Y-8 Airborne Warning And Control System (AWACS) aircraft which is China's effort to built an indigenous AWACS system. The Chinese AWACS, a typically secretive project that Beijing began after its efforts to acquire Phalcon AWACS jets from Israel was blocked by the US in 2000

Y-8 Project is said to provide a light, cheap airborne early warning and detection aircraft that can be produced and deployed in large numbers. Islamabad is expected to sign up to join the project and place orders after the operational demonstrations at Chaklala are over.

AWACS platforms, basically advanced radars mounted on aircraft, provide greater detection and coverage range than ground radars simply by virtue of their altitude, and provide a capability that both India and Pakistan are already in line to acquire.

In June, Pakistan signed up to acquire six Swedish Saab-2000 Erieye AWACS, more than two years after India ordered three Israeli Phalcon jets. But these are both expensive, limiting the numbers that can be acquired by either country.

A point of concern to the IAF is that the Chinese AWACS is near test readiness, which means Islamabad, when it chooses to buy them, will be in a position to deploy it in large numbers far before the Indian homegrown airborne early warning project, under development by DRDO's Centre for Airborne Systems (CABS) in Bangalore, actually takes off.

A senior IAF officer said, "Historically, decisions between China and Pakistan happen much faster. That means, they could have a greater density of airborne radar coverage before we do."

Long-range airborne radar coverage will be principal factors in ensuring that no air violations take place on either side.

Copyright © 2006 India Defence. All Rights Reserved.

maglomanic said:

Tp,

I know about OSI model (from like 3-4 years ago when i first enrolled in my computer science bachelors program).

See here is the thing. Link 16 is just a standard. How you implement it totally depends on the vendor. Each layer that you described could be implemented by seperate vendors differently as long as they adhere to the standard's requirements.

Lets say there is a requirement for a resend function. Specification of it's arguments and return value down to performace throughput. As long as a vendor is able to adhere to those requirements it doesn't matter what tool they used or what algorithem they designed. Thats the basic idea behind information hiding and exposing the interface (similar to the whole class constructs deal in OOP).


Now back to the link 16 deal, you can have two implementations of the same protocal but might not give you what you are looking for in terms of performance subjective to your environment and platform. For example, i have a wireless card designed by intel. My windows driver works just fine with it but it works super fine the driver intel provides. Now both vendors can design software for the same hardware knowing that it's fabrication adheres to certain standard. But performance wise you would need to know your hardware better.

Incase of Chinese AWACS it is their hardware they know it inside out. WHat algorthem they use to adhere to link 16 requirements shouldnt be a biggie as long as it's their hardware. Reverse engineering someone else's hardware is also doable and possible (i have a reverse engineered driver on my linux installation which is just as good as intel's but requires me to do a lot of customization and ease of use sucks).

just a link which describes some high level requirements for TDIL-J or Link 16
http://www.rand.org/pubs/monograph_reports/MR1235/MR1235.chap9.pdf#search='TADILJ%20standards'

Click to expand...

look man, you know I graduated from SE, there is no need to wave around our diploma around here.

As for the second pdf, it contains message specs and nothing else. That seems to be something that I would use at the application level. Again, the first pdf is also high level.

My point is this, you can have two systems using two set of hardwares. Both systems can abstract their low level stuff to the point that they provide a common interface. Your example doesn't work, since both side are using 802.11 protocol. But if you have two systems using even the same set of hardwares but abstracting lower level to two different interfaces. You are going to have problems.

And as I said, there is no indication that China is using link 16. Even if it uses the exactly the same message formats as link 16, there is no guarantee that it will be using the same protocol to transport these messages.

Now, just a small example, 802.11 has different maximum size of packet than 802.3? And they are both using TCP/IP protocol. So, there you have two different messaging protocols, but they use the same transport protocol. So, the message size has no relevance over the lower level implementation. It's an application level protocol.

but suppose you are trying to transport a message through the ethernet. Sender uses UDP and receiver uses TCP/IP. Sender would just send the message pack over and the receiver expects a connection first before sending. So, even if a packet is sent over, receiver would just ignore it. That's why when they are doing network protocols (check the one for C), they have two set of libraries, one using UDP and the other using TCP/IP. You cannot send using UDP methods on one side and expects to receive it on the other side using TCP/IP methods.

tphuang said:

look man, you know I graduated from SE, there is no need to wave around our diploma around here.

Click to expand...

Not waving my diploma. Just telling you i am aware of the OSI model since you kindly went into alot of detail regarding the OSI model.

As for the second pdf, it contains message specs and nothing else. That seems to be something that I would use at the application level. Again, the first pdf is also high level.

Click to expand...

Not necessarily. Isn't that what you pointed to that a protocol developer has to know the header size and such?
Message specs is the basis of Link-16 standard. J message. If i am gonna design a device that sends data in J-message format i would need all that info to design my ports.

My point is this, you can have two systems using two set of hardwares. Both systems can abstract their low level stuff to the point that they provide a common interface. Your example doesn't work, since both side are using 802.11 protocol. But if you have two systems using even the same set of hardwares but abstracting lower level to two different interfaces. You are going to have problems.

Click to expand...

I gave you example of use of MIL-STD-1553B bus.If JF-17 is using this bus then it can be hooked up to western weapon systems which adhere to the standards on which this bus is fashioned. Now i am not sure why your skeptical that Chinese didn't make sure that their hardware is compatible to western technology. That would be bad design to begin with. Last thing i would expect from industry that has learned so much from west.
Incase of a system like AWACS thats even worse. It's all about sending information and communicating.

If you have standard specs available then implementation is not a problem.

And as I said, there is no indication that China is using link 16. Even if it uses the exactly the same message formats as link 16, there is no guarantee that it will be using the same protocol to transport these messages.

Click to expand...

Again, thats adhering to a standard like i said before. Protocol is the whole point for having a communication link between different devices who adhere to it. I explained that how implemetation is decoupled from protocol.I don't know why it doesnt make sense to you.

Now, just a small example, 802.11 has different maximum size of packet than 802.3? And they are both using TCP/IP protocol. So, there you have two different messaging protocols, but they use the same transport protocol. So, the message size has no relevance over the lower level implementation. It's an application level protocol.

Click to expand...

Whenever such situations arise there are always ways around them. Like i said emulation is one such thing. A software sitting on top of your hardware that would try to understand the different format coming from the other end and convert it into what your device can understand.
The same emulator could be implemented into hardware.

but suppose you are trying to transport a message through the ethernet. Sender uses UDP and receiver uses TCP/IP. Sender would just send the message pack over and the receiver expects a connection first before sending. So, even if a packet is sent over, receiver would just ignore it. That's why when they are doing network protocols (check the one for C), they have two set of libraries, one using UDP and the other using TCP/IP. You cannot send using UDP methods on one side and expects to receive it on the other side using TCP/IP methods.

Click to expand...

you are talking about two different modes of communications on the virtue of different protocols. I have been all along talking about ability of chinese to adhere to the same set of rules that would allow a Chinese AWACS to communicate to a western Jet. One protocol.
The standard is out there, all the need to do is implement when they send data in what format, expecting what in return.

maglomanic said:

Not waving my diploma. Just telling you i am aware of the OSI model since you kindly went into alot of detail regarding the OSI model.

Click to expand...

Not necessarily. Isn't that what you pointed to that a protocol developer has to know the header size and such?
Message specs is the basis of Link-16 standard. J message. If i am gonna design a device that sends data in J-message format i would need all that info to design my ports.

Click to expand...

it depends on how much abstraction you want to do, really. If you are programming and using the java socket library, you don't really need to know anything. But if you are developing the actually socket libraries, then you would need to know the header size and such.

I gave you example of use of MIL-STD-1553B bus.If JF-17 is using this bus then it can be hooked up to western weapon systems which adhere to the standards on which this bus is fashioned. Now i am not sure why your skeptical that Chinese didn't make sure that their hardware is compatible to western technology. That would be bad design to begin with. Last thing i would expect from industry that has learned so much from west.
Incase of a system like AWACS thats even worse. It's all about sending information and communicating.

Click to expand...

it's not about hardware. It's about using your own network protocol. Chinese are very paranoid. It would surprise me very much if they use Link 16. Even the Swedes have their own protocol. they just happened to also implement link 16, that's all.

Again, thats adhering to a standard like i said before. Protocol is the whole point for having a communication link between different devices who adhere to it. I explained that how implemetation is decoupled from protocol.I don't know why it doesnt make sense to you.

Click to expand...

as I explained, there is a difference between messaging and transport/network protcol.

Whenever such situations arise there are always ways around them. Like i said emulation is one such thing. A software sitting on top of your hardware that would try to understand the different format coming from the other end and convert it into what your device can understand.
The same emulator could be implemented into hardware.

Click to expand...

that was my point about messaging protocol not as important and can be solved using software.

you are talking about two different modes of communications on the virtue of different protocols. I have been all along talking about ability of chinese to adhere to the same set of rules that would allow a Chinese AWACS to communicate to a western Jet. One protocol.
The standard is out there, all the need to do is implement when they send data in what format, expecting what in return.

Click to expand...

i think I've been clear all along that China is not using link-16. The standard is not fully out in public. Messaging protocol is just the start of a huge protocol. Knowing the messaging protocol means nothing. Besides, why would they use link 16? There is plenty of networking research done for different degrees. I'm sure China can do better than link 16.

tphuang said:

it depends on how much abstraction you want to do, really. If you are programming and using the java socket library, you don't really need to know anything. But if you are developing the actually socket libraries, then you would need to know the header size and such.

Click to expand...

But when you build a device that is compliant to a standard and protocol you need to know that.

it's not about hardware. It's about using your own network protocol. Chinese are very paranoid. It would surprise me very much if they use Link 16. Even the Swedes have their own protocol. they just happened to also implement link 16, that's all.

Click to expand...

They can have their own protocol, thats ok, but if their device capable of getting connected in an environment that uses Link 16.

Your protocol can tell you how many bytes will be reserved for private key of your encrypted message. It however won't tell you which encryption method to use. As long as you follow the standards it's pretty flexible in terms of implementationa nd security. All the countries that use Link-16 do their own implementation. That doesnt mean they are putting their security in the hands of US or that US can do whatever it wants to.

as I explained, there is a difference between messaging and transport/network protcol.

Click to expand...

Protocol is the method of sending message.

i think I've been clear all along that China is not using link-16. The standard is not fully out in public. Messaging protocol is just the start of a huge protocol. Knowing the messaging protocol means nothing. Besides, why would they use link 16? There is plenty of networking research done for different degrees. I'm sure China can do better than link 16.

Click to expand...

Chinese are not using it ..and i can totally agree with you on that. However your point that they cannot make their systems Link-16 compliant because they don't know the standard or cannot possibly implement is entirely different. There are more than one ways that it could be done.

Like i said as long as you have native API that provides you interface to underlying hardware and is robust enough,it can make two devices talk.

How about a mainframe from 70s that uses tapes for data storage and a modern xeon server talking to eachother. Interestingly major part of it was done using pascal and even cobol for some mappings. And i don't think anyone would consider these tools as robust as modern day languages and it was done in short time without too much problems. Talking from personal expereince.

maglomanic said:

But when you build a device that is compliant to a standard and protocol you need to know that.

Click to expand...

yes, again, this is all application level

They can have their own protocol, thats ok, but if their device capable of getting connected in an environment that uses Link 16.

Click to expand...

that's the point I'm making if you use another protocol, it is very unlikely that it can connect to link 16. For example, if you use UDP, it doen't even require a connection with the other side.

Your protocol can tell you how many bytes will be reserved for private key of your encrypted message. It however won't tell you which encryption method to use. As long as you follow the standards it's pretty flexible in terms of implementationa nd security. All the countries that use Link-16 do their own implementation. That doesnt mean they are putting their security in the hands of US or that US can do whatever it wants to.

Protocol is the method of sending message.

Click to expand...

that's not what the protocol is about. The protocol is about how you send and receive the data. How you guarantee delivery and what to do when you get too many collisions. Encryption is a very small part of it.

Chinese are not using it ..and i can totally agree with you on that. However your point that they cannot make their systems Link-16 compliant because they don't know the standard or cannot possibly implement is entirely different. There are more than one ways that it could be done.

Like i said as long as you have native API that provides you interface to underlying hardware and is robust enough,it can make two devices talk.

How about a mainframe from 70s that uses tapes for data storage and a modern xeon server talking to eachother. Interestingly major part of it was done using pascal and even cobol for some mappings. And i don't think anyone would consider these tools as robust as modern day languages and it was done in short time without too much problems. Talking from personal expereince.

Click to expand...

they can't, it's not about native API. Even with time changes, the protocol of transport/network is still the same between a mainframe and a xeon server. Or at least it implemented the protocol of that old mainframe. I'm telling you right now that China is using one transport/network protocol and Link-16 is a different one.