OK, absolutely mandatory first comment: DO NOT ROLL YOUR OWN ENCRYPTION PROTOCOL OR WRITE YOUR OWN CRYPTOGRAPHY IMPLEMENTATION. Just don't. Ever. It doesn't matter how great a programmer you are; if you don't have a lot of knowledge and practice with crypto and a group of similarly skilled-and-experienced peer reviewers, you will screw something up. Crypto is extremely difficult to get right, full of edge cases, counter-intuitive requirements, and unexpected side-channels... and if you fail to account for even a single one of them, you'll weaken your scheme, quite possibly to the level of complete compromise.
Edit
OK, I'm not familiar with the scheme described in that paper. Given that, the below stuff - for use with normal DH exchange, not this curious new thing - may not be appropriate. However, The question you asked, "How to Perform Encryption after Diffie Hellman Key Exchange", is answered below... except, of course, that the true answer is "you don't, you use a library that handles that for you."
Ok, with that out of the way... once you've got the symmetric key out of the DH exchange, use it in a symmetric cryptographic cipher! There are lots to choose from, but the most common is probably AES, using either a 128-bit or 256-bit key, in CBC mode, with PKCS7 padding, using a strong randomly-generated IV, and with an HMAC of the ciphertext for integrity. If your shared key is the wrong length for the cipher, you can run it through a function such as SHA-256 to produce a key suitable for 256-bit AES.
You can send the IV and the HMAC in the clear; they are useless to an attacker without the key and the intended recipient needs to know them. The recipient takes the ciphertext, re-computes the HMAC and verifies that it matches, then uses the supplied IV and the shared symmetric key to decrypt the message using the same AES cipher in CBC mode.
I cannot emphasize strongly enough how essential it is that you do NOT attempt to do this as anything but a curiosity. Do not publish this code. Do not incorporate it in anything you might ever publish. Do not build anything else on top of it. Do not trust anything sent via this system. Do not assume it has any meaningful security characteristics. Ideally, don't even stick it in your GitHub or whatever... but if you must, include a comment at the top very clearly disclaiming the suitability of the code to be used for anything whatsoever.
There are steps I've elided over or left overly vague. There's at least a dozen ways you could screw up even just the parts I've told you about, never mind all the other things you have to do. There's a bunch of stuff I suspect you've already done wrong in your key exchange. There are a bunch of things that I'm sure I don't even know are wrong, but that you're doing wrong.
I've been in InfoSec professionally for eight years, with an interest in crypto that goes back four years earlier than that, and at this point when I review homegrown crypto code I can give two meaningful answers: "It's broken" and "It's probably broken". I don't know enough to even tentatively state that something home-grown is not broken, and that will probably be true for the rest of my career unless I decide to devote a decade of my life to this specific area of security. Crypto is hard!
There exist libraries, written by people who know more about crypto than practically anybody else alive today, that will do pretty much any cryptographic task you ask of them. There are protocols, designed by similarly-experienced people and implemented with great expertise in those libraries, that turn cryptographic primitives (like DH key exchange) into a useful cryptosystem. Even so, bugs and weaknesses in those libraries are found all the time... but at least they're fixed quickly. You will NOT do any better yourself.
