This goes to cryptographic protocol design.
The first parts of your encrypted payload, when decrypted, will likely be quite guessable, because it will contain things like sequence numbers, object IDs, packet type IDs, and so forth, that all take a fairly limited set of values.
This means that, if someone has a large number of packets encrypted with the same key, and know enough about the first 8-16 bytes of the payload, when you use a single IV for every packet they will be able to use differential cryptoanalysis to break the session, recover the key, and then decrypt the entire session.
However, when you use a different IV for each packet, the differential analysis doesn't work, and your key can stay secure. The problem is that the receiving end needs the IV to be able to decrypt each packet, hence the IV is generally prepended to the packet payload. As opposed to the key, the IV doesn't need to be secret; it just needs to be sufficiently different between packets.
An alternative, that "should" be as good, but has not had the seal of approval by crypto designers, is to use a good random number generator to generate 16 bytes of random data, and put that first in your encrypted payload. Because there is no similarity to look for, and assuming you don't use "ECB" mode for your cypher (you REALLY shouldn't!) then this will similarly confuse the differential attacks. The receiver would then decrypt the payload, throw away the first 16 random bytes, and recover the message you sent. This has the same overhead as sending the IV in the packet, and accomplishes the same thing, but is not the "recommended" way by cryptographic experts.
There exists a protocol called DTLS which is approximately TLS/SSL over UDP. If you don't want to implement your own, you can use that. It may have slightly higher overhead than a to-the-metal implementation, because it also provides additional features and flexibility, just like TLS has overhead on top of TCP, and provides additional features.