Hi Kian,
As you described your issue, it might come from a very simple thing, however it needs to be confirmed.
It would be great if you can confirm exactly when the issue occurs because you mentioned it failed after 15 minutes but I guess you mean it fails 15 minutes after the data.zip has been successfully created on your SEPM Master Site (US Server), Is it correct ?
Anyway you can verify that very easily.
Check on the SEPM install folder of your US Server, you will have basically the data.zip file located to the following directory.
%Symantec\Symantec Endpoint Protection Manager\data\replication\outbox\
Then a folder with a very long ID and then inside you'll find a folder data or data.zip depending if it's successfully created until the end of the process.
At least you can even try to run again the replication from your ASPAC Server and see if the data.zip is successfully created on your US Server in the outbox subfolder of replication folder.
On your ASPAC server then you can see if you're receiving or not progressively in the Inbox subfolder of replication folder your data.zip
From what you described, I would say your replication issue may come from 3 different and possible sources.
1) Special caracters used on SEPM and Database password.
If you're using special caracters on the password of your SEPM and your Database. The connection to the remote will fail straight way. If you're in this situation. I would advise you to reset your SEPM password and dba password as well with only digits and letters and try to run the replication again from scratch on your ASPAC server.
Please note that using special caracter on your database will make you unable to perform a load Database tasks like restoring a Database from a Backup and Replication.
In later releases it will not be a problem anymore.
2) Network bandwidth issue/Packet loss during data.zip transfer
You're already using a simple password for your current US SEPM and Database server, there is some packet drops that occurs during the transfer of the data.zip which results a time out during the replication.
In this situation, I would recommend to follow the instructions from the KB that Sachin already mentioned on the post before.
How to Perform Offline Replication between 2 Remote SEPM
http://www.symantec.com/business/support/index?page=content&id=TECH95122
/!\ Note that if you have a sort of proxy or firewall set on the network that use your both servers to communicate each other, ensure the time out settings have been increased because replication performs TCP connection with port 8443 and may stay in idle during all the replication process (especially during data.zip transfer) and it even might take a long time as your current database size is 16Gb so the data.zip to transfer between the both server during the first replication will be for sure over 8~10Gb.
3) LiveUpdate/Replication Conflict
If a Live Update session is running on your US Server during the replication, as Live Update is using a common process with the replication which may result that Live Update forces the unlock of this common process used by the replication in order to run in priority over it.
In this situation, just change the schedule of your Live Update on your US Server and run it once manually in order the changes performed on the schedule are applied and then wait to run your replication during hours when Live Update is not supposed to be running.
Hoping that helps 
Kind Regards,
A. Wesker